How to manage passwords in application configuration

Question

I'm working on a system that interacts with many external system API:s. Most of them require authentication of some sort. For the sake of usability there is an "application wide reachable" AppConfig that stores configuration info, as well as credentials for the external systems.

My question is if it is a bad idea to store usernames and passwords (in cleartext) to the external systems in the application configuration file. If so, how do you avoid it?

In order to access the configuration file you either have to compromise the server's file system, or the git repository on another server (or, of course any developer's system). I'm been thinking that encrypting the password in the configuration file does not increase the security level, as the encryption key has to be stored somewhere as well. Am I wrong about this?

I would really appreciate answers explaining how you have solved this issue.

Solution

Ok, so here is my final solution. I created a simple library using OpenSSL to encrypt and decrypt my sensitive data. The key is retrieved from the user when the configuration is loaded, except on the production servers where it is stored in file. It is still not an optimal solution, but it is way better than the "solution" I previously had.

Thank you for your answers. I will accept Wayne's answer as it was the most informative.

Answer 1

Good security is hard.

As Bruce Schneier says, "Security is a tradeoff." You have to decide how secure you want this information, and how much time you want to spend securing said information. And you definitely don't want to leave passwords just sitting out there in plain text, that's a no-no. If you're in a situation where that's OK you're in a situation where you shouldn't have user authentication.

Even though security is hard, there are a few things you can do.

1) Use some type of compiled program to do the encryption/decryption. You don't want someone to open up a Python/perl script and say "aha, this is just a simple XYZ encryption", though ideally you don't want a simple encryption.

2) Security through obscurity is not real security, but it can help against the casual snoop. For instance, naming your file "passwords.txt" is not a terribly good idea, but encrypting your passwords and then using steganography to hide the user/pass in some image file is better.

3) Look up strong encryption/decryption algorithms. Some of them are already implemented in most languages and you can just import a library. This can either be bad or good, depending on how secure you think you want this stuff.

But honestly, this system is really bad - security wise. Ideally you have a two-party authentication and then the trusted middleman does all the wheeling and dealing. For instance, when you log onto your computer you're telling the computer that you're an authorized user. From there you get to run all of your programs and they don't ask or care about your user/pass combination - just that you're an authorized user. They get this information from the OS (the middle-man). Heck, even SO uses openID to decide that you're a trusted user - they don't care what your credentials are on the other sites, only that the other sites say "Yes yes, this is a valid user."

If you have the option, I would seriously consider switching your authentication model. If not, good luck.

Answer 2

Regarding real live examples, web servers store database login details on the server, in plain text. If someone gains access to your server, you are screwed anyway. But protecting those passwords from the unwanted opportunistic intruder, well personally I like the extra layer to feel safer. Better safe than sorry, right?

Since these passwords are for external systems, it would be prudent to secure those with another layer: encryption. Yes security through obscurity is bad, but don't you think it acts as an excellent deterrent if someone had to stumble onto them - Plain text passwords just beg to be taken.

I recommend using 1024 bit encryption, there's a couple good algorhytms. I also recommend using a 64/128 bit random salt for every entry you encrypt, so that even if the password for one entry is brute-forced, the solution won't work on other entries. Random Salting prevents Rainbow table attacks, which forces your cracker to use brute force, much more time consuming.

Yes these precautions seem paranoid, but if I try and crack my own passwords (for research interest, of course) I can imagine what some malicious minded person might try.

Edit: An example of how the salt makes encryption more secure, even if the encryption key is known.