Friday, September 23, 2011

Random musing on password storage in webapps

A (loosely-formed, potentially already-implemented) thought:

For security's sake, it's blasphemous to store passwords in plain-text; using a hash function and then doing a re-hash and comparison is considered much better.

But, if bad guys steal your database, they still could brute-force against the hash and conceivably retrieve many passwords.

The question I have is: Is salting a hash as effective for the effort as say, combining multiple encryption methods with a signifier?

For example, Let's say MD5 = 1, DES = 2, and AES = 3. During the first time the password is stored, why not generate a random sequence of these numbers (i.e. "231"). Then, hash the password in that order (e.g. for "231", DES, then AES, then MD5) and add the digits to the front. Then, comparison does all three hashes in a random way, by taking the first three digits to see how it should be decoded.

I know this is more computationally expensive than a salt, but given the random algorithm assignments plus the task of brute forcing (and taking into account that the attacker would have to have source-code access to see your enum of what numbers are what, etc.), would it be more effective?

Update: In case you'd like to follow along, I posted the question to the StackExchange Security site, so that people much smarter on this than me could weigh in.