2

Note: this is a cross post from my question on SO. Feel free to keep the one in the more relevant location and close the other.

We have a rails app which will be deployed on torquebox/jboss. (This in a way does not matter too much for the question as it would apply to any Web app, not just a Rails one.) It retrieves certain app-level sensitive configuration variables from the environment, such as ENV['DATABASE_URL'] (which includes the auth credentials so it looks like drivername://user:pass@host:port/dbname) and ENV['PEPPER'] when it starts up, to do essential processes like connecting to the database. The variables are not encrypted at this time. In essence the use of the environment to hold these variables follows the 12-factor app Heroku playbook.

There are in a way two questions here:

  1. Is it PCI compliant to store such variables unencrypted in the environment at all?

  2. The environment variables need not come from the OS shell (the normal place where they would live). They could equally be set in jboss or torquebox if that would be any more secure eg against an attack like shellshock. Which ENV variable store should be used?

I am aware that there are alternatives, such as encrypting with DPAPI (but that is Windows only), using Java key stores (but that is limited to client certificate based authentication AFAIK, not plain old passwords), but they are more of a pain to use, and the use of environment variables seems so widely recommended even by PaaS providers themselves that I am wondering if we actually need to go the extra mile.

1

The DB URL (other than username and password) and Pepper aren't sensitive values. You may not want to advertise them, but you should assume they are known anyway. If your security is dependent on them being secure, then you are almost certainly not PCI compliant. Any "security" that that secrecy provides is just security by obscurity.

The DB should be inaccessible other than from your web servers and your pepper only exists to make hashing more difficult. I don't see why these particular values being accessible to the environment would be a problem since they aren't secret anyway.

The main possible problem would be that your DB credentials are kind of flying in the wind, but there isn't really too much a way around having to store it somewhere. You should try to restrict the access to the configuration data including the username and password for the DB as much as possible, but unless you go pretty elaborate, it has to be in a file somewhere. Make it as inaccessible as possible and make sure that only the systems that need access to the DB server have access and your risk is limited.

I'll let someone else speak up on the username and password specifically though as it has been a little while since I last had to deal with PCI-DSS and I don't particularly trust my memory or have time to look up the specifics at the moment.

  • Hi AJ, I have just updated the question to show that our database url (and other URLs like it) is a full connection string - it includes a username and password. Does this change your analysis? – user1475135 Nov 4 '14 at 14:55
  • @user1475135 - updated my answer to be consistent with that. Unfortunately, I don't remember the specific DB credential storage guidelines as I haven't had to deal with PCI-DSS myself for the last couple years. I'll let someone else speak up on that. – AJ Henderson Nov 4 '14 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.