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?
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.