Wednesday, 6 June 2012

Linked-In loses 6.1m un-salted hashed passwords - WTF does that mean?

... and why does it affect you?

This post is aimed at the layman.  If you're not particularly technical and want to know what this is all about, read on... 

Well firstly, it only affects you if you have or had a Linked In account.  Contacts of mine seem to be deleting their accounts in droves, but more about that later.   Chances are, their account data is possibly still hanging around.  Who knows for sure if your data is really deleted?

But what it essentially means is that someone might have your email address and password, and if you use the same combination of email and password on sites like PayPal, you could find yourself out of pocket!  So even though the warning is to change your password on Linked In - remember to change it on any sites where you use the same email address and password to log in.

Standard practice is not to store your password in plain text, but at the same time they need a way to compare what you enter when you login with what's in their database.   To do this, passwords are "hashed".  Hashing is a form of encryption.  You take some characters and apply an software process to it and produce some other seemingly random characters.  For example if you use the password "manchester" it isn't sat in their database as "manchester" for the world to see, it'll look like this "018a9567ea15470312c40d3e5d6bbcd4".

There are different algorithms for hashing.  The one I used above is called md5 and is not recommended for use in recent times, but is fine for demonstrating this point.

No matter how often you try, the md5 hash of "manchester" will always equate to "018a9567ea15470312c40d3e5d6bbcd4".   But it's a one-way operation... you can't take "018a9567ea15470312c40d3e5d6bbcd4" and reverse the process to find out that the input was "manchester".

However, what you can do is generate any number of md5 hashes easily enough.  So all a password thief needs to do is generate md5 hashes for a known list of inputs and compare them.  Thus, if they see "018a9567ea15470312c40d3e5d6bbcd4" in the list, then they know your password is "manchester".

The passwords were stored un-salted.  Why is salting important? 

Salting adds a layer of security to your password and this is really where Linked In failed.

Salt is a bit of extra data that is appended to your password before it is hashed with the result being stored in the database.  When you sign in to a website, they add the salt to whatever you entered as your password, hash the result and then compare it to what's in the database.  You don't add the salt when you sign in, the server does it for you.

But the important thing is, so long as the salt is secret then the passwords are now near-impossible to decipher.  For instance, using "manchester" adding the secret salt of "mouse" makes your password look like "manchestermouse" and now gives a hash of "63a1d6c2df05dc6919084c7d763b6622"... a totally different result!

Thus, unsalted passwords are nearly as unsafe as plain text passwords.

So in conclusion, you can't do anything about a site's security if it has been implemented poorly, but you can help to protect yourself using a strong password; at least 8 characters with a good mix of letters (uppercase and lowercase), numbers and strange characters like exclamation marks, hyphens, dollar sign, etc.

Another very important tip is to try not to use the same password across multiple sites.  If this is too tricky to manage, use a secure password service like  They have password generators and automatically inject your password in to forms on a web page, while storing your password securely on their servers.  Very convenient and if used correctly, very secure!


RobZed said...

"so long as the salt is secret " ... I'm not sure this is necessary. As I understood it, the problem with unsalted passwords is that you can create a rainbow table, i.e. all dictionary words - perhaps with some common variations (e.g. adding numbers at the end) and other well know passwords (1234, pa$$word, trustno1, qwerty, letmein, etc.). This is possible (say 100,000 md5 hashes). However adding 16 to 128 bits of salt makes a lookup table assisted dictionary attack against the stored values impractical...

Chris Brind said...

Depends where the salt is stored. If you use the same salt for all passwords and someone finds that salt, they can easily generate a new rainbow table. If the salt is derived from some other data (e.g. the user's surname) then yeah, it's more difficult. So the salt (or how to derive the salt) needs to be secret. In the case of a derived salt, it would be prudent to segment that data in case of loss/leakage.