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

Don't use passwords

[forsetti]

Passwords are for "Authentication". Your user has already been authenticated. You are now looking for "Identity Forwarding" or "Identity Session Management". Do not use passwords are your Identity Token. Look at technologies like Kerberos, which use your password for authentication, give you a identity token in the form of a TGT (Ticket Granting Ticket), and then allow you to request unique (and optionally forwardable) tokens for each service you are looking to access.

In the web world, CAS provides proxy tickets, which can even be forwarded (for example, to an FTP server) as a stand-in for passwords via PAM.

Re:Uhh

[Phillup]

I think when the parent refers to a 'hash' he means a perl hash, not a cryptographic hash.

Problem is retarded 'complexity' requirements

[Gothmolly]

Where I work, you must have a capital letter, and at least one number. You must change it every 4 weeks, and you cannot reuse any of the last 9. I consider this just on the verge of silly, but it can easily be circumvented like so:

Pick a person's name, say, Annakin.
Add a number or two to the name, Annakin123.
When the password expires, change to Annakin234, then Annakin345...
3) Profit!

Our AD guys are constantly battling the Infosec weenies who claim we need to have even stricter passwd policies, which will result in even MORE Post-It notes underneath keyboards.

If you share an account over which you have no control, get Passkeeper, or develop a "seed" algorithm, that knowing the code, and the seed word, and the hostname, you can derive the password, so you can easily remember it, i.e.

Seed is "slash"
Algorithm = seed + 3rd octet of hostname + first letter of hostname + last letter of hostname.
(or similar, I just thought this up off the top of my head)

Immune to all but dictionary attacks, and you and coworkers can easily derive it on the fly.
Potential security breach? Just change the seed word.