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.

Don't store passwords, store cryptographic hashes

[Anonymous Coward]

One approach is to compute a salted cryptographic hash of the user's password and store that instead of the password. A cryptographic hash is a fixed-length 'fingerprint' of some string and provides reasonable guarantees that, given a particular hash it is difficult to determine the string that created it (i.e. the original password) and that finding any string that results in the same hash is also difficult.

When the user submits their password (over an encrypted channel!), you compute the salted hash for the submitted password and test it against the one you have stored.

If your database of hashes is compromised, it is difficult for the attacker to find out the users' passwords, as you never stored them.

Now let's assume that an attacker gets your database of usernames and hashes. People are bad at choosing passwords, so it would not be suprising that two people woudl have chosen the same password. The attacker might take a dictionary of words and common passwords, compute a hash for each one (or just obtain pre-computed hashes for a dictionary) and then compare those hashes to each one in the user database. If they find a match, they have found the password. If two of the hashes in the user database match, the attacker has found two passwords.

If, before you compute the hash and store it in the database, you 'mix' (e.g. by pre-pending, appending or otherwise) a random string (called the salt, which is also stopred in the database) with the user's password, you can be reasonably confident that the attacher won't be able to easily tell that two users have the same password and will be forced to run their dictionary attack manually, by computing a hash for every combination of dictionary word and salt, for the commonly-used ways of salting passwords, which will make their life much much harder.

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.