[eluser]n0xie[/eluser]
[quote author="slowgary" date="1245228774"]What's the benefit of a random salt when it has to be stored in the database table? If someone gains access to the table, they have the salt. Maybe if you just used another field instead of having a salt field, the hacker would not know that the field had anything to do with the salt (user's email address, for instance).[/quote]
If you read my link you'd know
It's really simple actually. A rainbow table is a pre generated dictionary of hashes. So let's assume you take all the words in the English language and you take a few simple extra's (adding a 1 to the end, replacing the 'e' for a 3, the 'a' for a 4 etc etc.) and you hash all these words and save these along with the 'password'. You end up with a huge dataset of hashes. Now you compare those hashes to the 'stolen/ hacked' database. If a match is found, you just cracked a password. The very simple method of protecting against this is making sure the word is not in that dictionary. So you add a random piece of garbage data just so the 'word' isn't in the dictionary. The hash will come out different and voilà, your password can't be cracked.
The problem rainbow tables have is that it's impossible to store all the hashes, so they have only a small portion (even millions of key/value pares are considered small) of the most commonly used passwords. This is both a time and a speed limitation (which is basically all security is).
Now if you have a 'fixed' salt, and the salt gets discovered, an attacker could just simply generate a rainbow table, based on your salt, thus rendering the salt obsolete. Using a random salt, an attacker has to regenerate the entire rainbow table for EACH row in your database for that particular salt. So even though he has the salt, it would take him years (if not longer) to decipher even a fraction of all the passwords.
Quote:Also, does it really matter what you use to hash passwords with? Unless they have direct access to your database, a brute force attack would be done using actual dictionary words, not hashed words. Your site should not allow someone to fail more than a few login attempts before they're locked out for a short time and you log their info.
Preventing against a brute force dictionary attack is common sense, not security
. To prevent people from shooting their own foot, the most used practice is to make the retry time exponentially long. So the first few tries are free, after that the retry time goes up for t = e^x.
Also never underestimate 'losing' a database. Sure most people are very careful when it comes to the live site. But how about backups? How about human error? How about common theft? Physical access to the machine? The list goes on and on.
