Storing Credentials for Secured Resources?

diverman asks: "It is very common for web applications (be them Java, Perl, PHP, .NET, or shell script) to need knowledge about credentials to access another resource. Perhaps it's a relational database login, an FTP account for transferring files, or maybe a authentication credentials to another web service. Whatever it is, most developers have likely had to write a program that needs to keep a password for later use. The big issue now is: where do you put them?" "Having passwords sitting around in clear-text isn't the wisest of ideas, and is against most security 'best practice' guidelines. Some apps and servers have chosen to base64 encode it (I believe WebSphere does this), and that's about as safe as clear-text. What I've been trying to find is a mechanism that behaves like how Apache loads properly signed SSL certs, that require a password when starting up the web server. The password could be used to decrypt a key-store for various application/resource credentials, and then make them available. Exact implementation isn't the question, as much as ANYTHING that does this at all. Are there any Apache modules that can place authentication information in ENV variables for executed apps, after decrypting them on server startup? Are there ways to have Java containers do something similar? It seems like this is something that is a very common problem, but not a very common question, with an even less common solution."

Comments

Re:Most?!?

[swillden]

Which security guidlines say it is ok and what companies are using them?

Companies that build real security systems often intentionally store on-disk passwords in cleartext, just to make the point that on-disk passwords are inherently insecure -- no matter how you obfuscate them -- and to encourage the use of hardware security modules.

Re:Most?!?

[swillden]

Personally, I consider El-Gamal to be encryption rather than "obfuscation", and quite happily store authentication token ciphertext in mysql.

And where do you store the decryption key? It's still just obfuscation, no matter how good the cipher is, as long as the attacker can get the key.

Re:Don't use passwords

[swillden]

Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management".

Sometimes. In other cases, what you want to do is to authenticate the server that is making the request. The user's identity isn't relevant, and that user may not even have any privileges to use the protected service directly. Instead, the "front end" service cares about who the user is and is willing to make some requests of the back-end service on the user's behalf, so it's actually the front-end service you want to authenticate to the back-end service.

The scenario you describe also makes sense, and also happens, but it's not the only situation that needs to be addressed.