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: 
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](https://stackoverflow.com/questions/30946/simple-password-encryption). I also recommend using a 64/128 bit [random salt](https://stackoverflow.com/questions/1745114/comprehensive-information-about-hash-salts) 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.](http://en.wikipedia.org/wiki/Salt_(cryptography)#Examples)
Some webbservers need to load symmetrically encrypted certificates on startup. To deal with this, they ask for password input on startup. So that it is only stored in memory.

Pros:

* Master password is never stored on disk.
* Master password cannot be extracted from `ps fax`.

Cons:

* Master password can still be extracted by memory dump (by the user running the webbserver and root).
* Your process cannot automatically be restarted without user intervention. This is probably the biggest reason why not more people go with this option. Luckily, webservers rarely crash.