For security\'s sake, of course it\'s blasphemous to store passwords in plain-te
ID: 651285 • Letter: F
Question
For security's sake, of course 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 the sake of 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 of the hash. Then, comparison does all three hashes in a random way, by taking the first three digits to see how it should be compared.
I know this is more computationally expensive than adding a salt before hashing, 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?
Explanation / Answer
1st, you know that AES, etc, are for encryption, right? Don't consider using "encrypt the password" because if someone gets your key, it can discover all your secrets.
2nd, the problem with hashes is the speed. That's why the best approach is to use slower hashing algorithms. While it'll make your login take longer (let's say, 100ms), it also slows down the brute-force attack. So it's good for you. That's where Bcryp, pbkdf2 and scrypt comes to help you.
3rd, don't do the hash just one time. You should do a hash(hash(hash( ... ))) a lot of times.
4th: use salt to make it harder. That way you'll add more entropy to the user password, avoiding the "common password" problem. A good salt is a very random one, one salt for each user.
And, in the end: don't forget other security points of your application. For example, if you add the "secret answer" scheme to your site, and them forget to secure the answer the user provides, all your effort might be gone as well.