Storing Passwords Encrypted in Database

Question

Hi there guys. Today I came up with a question about the web application conventions.

For the sake of security, if we store passwords of our users, most probably we are encrypting it (with MD5, SHA-1 etc.) and storing digested-hash in order to make them difficult or impossible to reverse.

Today there are many Rainbow Tables that are lookup tables of usual A-Za-z0-9 sequences up to 6 chars or widely used passwords. Let's say you are MD5-ing the user password once and storing the hash as password in database and someday hackers pwned your database and now they have many md5 hashes and e-mail addresses. Surely they'll look up passwords and when they got a preindexed match, they will try to login to that user's e-mail account.

Here this can be easily solved by digesting the message twice or simply reversing it. However I am wondering about what is the convention about this problem and how (as far as you know) enterprise applications or giants (Facebook, Google) solve this?

Answer 1

You use what is called a salt. Prepend some string that you make up before hashing. Prepend it also when you are checking the password. This is an application-wide string. This makes it much harder to look up via a rainbow table.

So if your salt is "kdi37s!!" save this in the db md5(kdi37s!!P@$$w3rd) and do the same when checking.

Answer 2

Use a little bit of salt and make a hash using sha1 or so.

Answer 3

Check out PBKDF2, it is one of the correct way to do it.

Answer 4

If you use an algorithm like BCrypt and salt (which uses the blowfish block cipher), it makes your db pretty safe against brute force attacks. Naturally, you want to require that your users have a reasonable amount of complexity in their password, if a user's password is a its not going to take long to guess it.

If an attacker gets a copy of your db, only being able to try 10 or so passwords a second will mean it will take a real long time to gain any passwords. If you are worried about Moore's law and would like to future proof this, you can specify a cost and make the algorithm even slower.

The trouble with a pure SHA/X or MD5 password hash is that by-design these algorithms are very fast, this makes it very sensitive to brute force attacks. Of course if you don't salt your hashes there are tons of rainbow tables that make cracking all the passwords in your db trivial.