My workplace has a standard that plaintext passwords are not allowed in application configuration files. This makes enough sense on its face, in case someone gets access to the config files they don't automatically have access to all the privileges of that application. In some cases it's possible and obviously preferable to have access associated with the login or otherwise avoid having a password, such as in Windows Security for SQL Server authentication, or have it configured in a third party location, such as JDBC configuration in a J2EE environment, but this is not always possible.

  • When I must have a password in a configuration file, what level of encryption should it carry?
  • How do you deal with the fact that the encryption key for the password has to be either hard coded or stored in yet another config file?
  • Should the encryption keys for password be human readable?
  • 3
    If your organization has that policy, maybe you should find one of the security contacts at your organization to find out what they find to be approved mechanisms for addressing that policy.
    – atk
    Commented Nov 19, 2013 at 20:57

5 Answers 5


So the following was a bit too long for a comment...

Perhaps taking one step back and comparing benefits of preventative and detective controls might help. Preventative controls include encryption but you could also encode the password to make it less obvious. This approach is meant to protect the password from accidental sharing (a b32 encoding would produce less meaningful characters (b32 produces longer string than b64). Such an approach just increases the difficulty of memorizing the random sequence of numbers as well as the method that should be used to decode the string. Base32/64 encoding is a simple way of protecting passwords that do not require additional logic to be built/maintained.

The other approaches to preventative controls would likely use encryption. There are many different ways to protect the key. Without getting into the details or reiterating what D.W. already posted, you can layer detective controls to improve the security posture. For example, you can audit access to a file that contains the key. You can correlate events (such as restarting of server/service) with access to the key file. Any other access request (successful or not) to the key file could indicate abnormal activity.

To get to your questions, here's my take:

if you have to store password in a config file, I'd recommend at least encoding the password where possible. Encoding the password would reduce the chance that it's leaked in the event someone scrolls through the file, say with a vendor support rep watching. Encrypting the password is much safer, but that requires additional complexity.

How to deal with the fact that a key has to be hard coded or stored in another file. Well, separating the encryption key in another file increases the difficulty for someone to view the key. For example, you can use access control to limit access to the key file but still maintain a more open ACL for the config file. Similarly, you can implement auditing for access to the key file, which you can use to correlate back to events that require use of key. Hard coding the key may be fine if you limit access to the binary. Careful encoding of password can easily be detected by running a "strings" against the binary. You can encode/encrypt the hard coded password (i.e. require a separate function (perhaps with auditing) when to decode the password, but that increases the complexity for the developer and admin (i.e. how does one change the key without rebuilding/recompiling the binary?).

Should the encryption keys for password be human readable? It depends. There's only a limited number of ways to protect the key. An encryption key is usually seen as an alphanumeric string that's hard to commit to to memory. You can always encode/encrypt the key, but such methods doesn't deter someone that's smart enough to take a screen shot. However, you can use simple "keys" (more like passwords) as input to a key expansion function. In those instances, perhaps additional measures such as encoding adds some additional value relative to the cost of complexity.

If anything, a good approach is to implement multiple layers of controls. Preventative controls are more difficult while detective controls are generally easier to implement. Separating key files could simplify the overall architecture and implementation of controls. Regardless of whether preventative or detective controls are used, enabling some auditing functions is a must along with review of audit logs. This way, should the improbable happen (access to key), you can take corrective action.


If you are running a server that needs a password for access to some remote service, then there's no good solution. Storing the password in a configuration file stored in a suitable location is probably making the best of a set of poor choices.

The choices are: have a user enter in the password at boot time (this is bad, because if your server gets rebooted, now the server is unreachable until a person can physically walk up to the server and enter the password); hardcode the password into the source code of the server code (this is much worse than putting it in a configuration file); or store the password in a configuration file (the least bad of all options). The main thing to watch out for with the configuration file, is to make sure it is stored outside of your web root and that its file permissions are locked down appropriately.

Encrypting the password that's stored in the configuration file doesn't help, because now where do you store the decryption key? You've just shifted the problem around. "It's turtles all the way down" is not an acceptable response.

On Windows, another option you might look at is storing the password in DPAPI. This helps a little bit for desktop applications, but is not very useful for unattended servers.

For more, read the following questions on this site: Store a password to avoid user interaction, where to store a key for encryption, How do open source projects handle secure artifacts?, How can I decrypt data with Java, without hard-coding the key?, Password in file .php, Where do I securely store the key for a system where the source is visible?.

P.S. In principle, you could use a TPM to store the password -- but in practice, this gets you into bleeding-edge issues, so it's probably not viable for most folks.

  • I agree with you in general, but can you address the particular issues in the question?
    – C. Ross
    Commented May 16, 2012 at 17:00
  • 5
    @C.Ross, Hmm, I thought I already did address all of the issues in the question. In short: encrypting the password in the config file is pointless, unless you have a better place to store the decryption key -- in which case, you might as well just store the password in that place and skip the encryption. So my flippant answer to your questions is: don't do that, that's just silly. Or, a slightly more serious answer: It might help if you could describe your threat model, and explain how you will protect the decryption key and why you can't protect the password in the same way.
    – D.W.
    Commented May 16, 2012 at 17:18
  • 2
    @lisa17 because when it needs to be changed (and it will need to be changed, no matter how much you deny it) the one that needs to change it will be FUBAR at best and with all private company data posted on The Pirate Bay at worst. Commented May 16, 2012 at 23:21
  • 2
    @lisa17 Also, if you hardcode it naively anyone can easily pull it out with the "strings" unix command.
    – C. Ross
    Commented May 17, 2012 at 0:38
  • 3
    @lisa17 In addition to good answers from HubertKario and C.Ross, see also my answer to this question for some more reasons: Password in file .php.
    – D.W.
    Commented May 17, 2012 at 4:46

Local password storage is a long issue i was dealing with. since encryption wont be bulletproof, but may help, there are few other options:

  1. store passwords on the local machine in a new file (which will be better to be encrypted as well) and restrict access to the file
  2. store passwords in another server, who will be authenticating through OAUTH or other authentication service - check out tahoe-lafs: https://tahoe-lafs.org/trac/tahoe-lafs
  3. using encrypted local service who stores passwords, and access it using Certificate
  4. some organizations store its passwords as registry keys or with DPAPI - http://msdn.microsoft.com/en-us/library/ms995355.aspx
  5. using OTP using account management service
  6. using proxy server to access confidential data and restrict access to the proxy


and for your questions:

When I must have a password in a configuration file, what level of encryption should it carry?

you never have to have passwords in your code, but it is the easiest way and the most insecure.

How do you deal with the fact that the encryption key for the password has to be either hard coded or stored in yet another config file?

using access restrictions and monitoring the file

Should the encryption keys for password be human readable? if you mean strong and human readable passwords, there is no problem at all

  • All these options seem to have the same "bootstrapping" problem. Say the password for your application is on another server, and you use an authentication service to get that password, how do you authenticate to that service (obviously, access to the service giving you your password would need to be authenticated...)?
    – Bruno
    Commented Feb 8, 2014 at 18:31
  • authentication may require some identity thumbprints for authorization. In case you are using firewall and NAC this problem should be mostly solved if you define specific barrier between servers. in case of certificates - it is hard to obtain the private key from the machine, and in case the user who is running the process has difficult-to-guess password it will be mostly secured. To be even more secured - usage of HSM may be the solution to store all keys Commented Feb 8, 2014 at 18:48
  • It really depends on the type of application we're talking about. I'd suggest most applications that require a password in a configuration file (as opposed to typed in by the user) are services, aimed to be running unattended on a server. In this case fingerprints or other user-based methods are not particularly useful (by lack of users to provide them). Some forms of OS-based protection (as you suggest) can help a little, though.
    – Bruno
    Commented Feb 8, 2014 at 18:55

Store the password in a (non-session) O/S user environment variable, and run the program as that user.


  1. You will never accidentally check the password into source control because there's no file to check in.

  2. If you screw up file permissions on your config file (which never happens right?), your passwords are not compromised

  3. Can only be read by user or root (same as a config file, same as a private key protecting an encrypted file)

  4. If you're encrypting the file, how are you securing your key?

  5. Clear your envvars before starting new processes though, as they may be passed through

One advantage to an HSM is that while user or root can use the HSM to decrypt a value, they can never get the key inside it.

  • How do you set the environment variable other than in some other file (such as ~/.bashrc)? Commented Jan 19, 2017 at 9:19
  • @AndreasMaier you would permanently store them in a file, yes, but not via source control. You want to use a configuration management system like Ansible. Commented Jan 19, 2017 at 18:42

My 2 cents here is that, for perfect security, you would want the application to be able to do something (read a password) that an attacker on the physical machine with the same privileges shouldn't be able to do, which seems a contradiction.

At best you could obfuscate the password in the configuration (Base64, key somewhere on the computer, etc...)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .