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: 
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.
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.