OK, now everybody should be aware that about 6.5 millions hashed passwords did leak out from LinkedIn.   On 6th June, the information was starting to buzz around.   The same day, LinkedIn confirmed that some of the alleged leaked passwords were real.  Soon the leak was confirmed and LinkedIn requested the compromised users to change their password.  I was among the happy compromised users.

What is the problem.   You never store passwords in the clear on the computer.  In fact, the good practice is to store the hashed password rather than the password itself.

 hashedPassword=Hash(password)

To test the validity of the password you check whether the hash of the proposed password fits the stored, hashed password.  The hash is the result of a one way function (SHA1 and MD5) are examples of such one way function).  It is extremely difficult (not anymore impossible in the case of SHA1) to create a valid entry of a one way function that matches a given hash value.  In other words, having a hashed password, it is extremely difficult to guess a valid password matching this hashed password.

Then, we are safe.  No.  Where is the problem?   It comes from rainbow tables.  Rainbow tables are huge precomputed values for a given known hash function.  Ophcrack is such an example of rainbow tables.  If the password is part of this dictionary, then it is extremely fast to find it.

Indeed, the good security practice for storing password is to use salted hash.  A salted hash is a one way function that uses an additional “secret” value called the salt.  In that case, usual rainbow tables do not anymore work.

hashedPassword=Hash(password + salt)

Unfortunately, it seems that LinkedIn did not use salted password.

Lesson: Use always the best practice in security.  If we are using so many tricks, it is often because there are good reasons.  Often the result of a lesson coming from a hack.