Managing and deploying web app passwords

Question

What are some best practices for managing and deploying web app passwords and private keys? E.g. the password to access a database or external services like the Facebook API. I'm referring generally to using dedicated hardware or a general cloud provider and not any specific provider like Heroku or EC2.

Is the best you can do without an HSM is to deploy the credentials in a plain text file to a read protected directory that can be accessed only by the web app user? Should you have one file with all passwords or a file per user or store in environment variables? How do you manage actually putting them on the servers? Can you use a configuration management tool (e.g. chef/puppet) to deploy them and keep them up-to-date? How should these credentials be stored? Should they be stored in encrypted format in the source control directory containing the configuration management configs? Any recommendations on tools to use that may be helpful? (e.g. keyczar, secret server, etc.) If the passwords are encrypted what's a good way to share the decryption key among the DevOps team? (LastPass, KeePass, etc.?)

I know that's a long list of questions, but these are all things that I haven't found good answers to. I'm interested in any info whether that's a case study of someone doing it well, trade-offs to be made between different alternatives, things that should be clearly avoided or aimed for. I really don't know what best practices exist and have helpful tools vs. what we just have to decide for our own situation and solve on our own.

Answer 1

Your question is very vague and covers a number of areas. An example would be most helpful.

Based on the title of your question, it seems you're interested in how to securely handle credentials that are required by an application. If this is a Microsoft environment one can encrypt sections of the web.config which is used to store sensitive information (SQL logon credentials, etc.). This post offers a good explanation: why-to-use-rsa-for-dpapi-web-farm-encryption. In short, if you have a single webserver DPAPI is the recommended solution whereas RSA keys are preferred for web farms.

However I believe you're also interested in a enterprise password management solution. SANS instructor Jason Fossen posted a great entry on his Windows Security Blog. He wrote a script that will assign a unique password to local accounts and leverages asymmetric encryption to save the password to a centralized location. In the entry he also mentions a number of commercial products in the Password Vault or Enterprise Password Management space.

HSM is typically only used for critical accounts like domain/enterprise administrators or for certificates used by critical infrastructure. For general or everyday use, these enterprise password management solutions are great.

Quite some time ago I looked into the Lieberman solution and found it to be very cool. There's full auditing to log the user accessing credentials, what credentials were access, and of course when. There's also flexibility to setup temporary accounts (only good for x time) which is useful for contractors, consultants, etc.

Answer 2

I think it would help to go back to some basic principals. A good starting point is to design things such that there is NEVER a reason for the application or administrators to know a users plain text password. You should only ever have the hashed/encrypted version of the password. If you never know the password, then you never need to or even have the option to communicate it with the user.

The next thing to do is a risk and consequences assessment. What are the main risks and what would be the consequences if those risks are identified. This will give you an idea of the level of security you require and what options are acceptable.

The problem then becomes one of working gout how to setup/register new users in a secure manner which satisfies your risk assessment. There are a number of options, many of which depend on what information you have. Most solutions rely on either providing a one time password or one time link that they can use. Both would have a timeout, after which period they would no longer be usable. When they use the password or link, they would be forced to set their 'real' password etc.

The problem then becomes one of working out the best way to communicate this one time password or link to the user. This will depend on a combination of both the options available i.e. private email, SMS, telephone, etc, and the risks and consequences should the info ration fall into the wrong hands.

The assessment of risks and consequences is critical. If the level of security and protection is not well matched with the level of risk and consequences, users are likely to be unhappy with the service. Either they will think it is not secure enough and avoid using it or they will find it too hard to use and avoid using it.