June 10th Update: I added a new GUI tool, to make it easier to check your password’s hash
If you have a LinkedIn account, you may be the owner of one of the 6.4 million accounts that have been recently hacked. You should check to be sure. If you have been hacked, your password has been forever compromised in all of your current and future accounts! In this post I will try to help you check whether or not you’re safe, explain what LinkedIn did wrong, and how and why all developers should be more careful.
First Things First: Was I Hacked?
I wrote a simple command-line tool that will help you check whether you were hacked or not. What you do is enter your password, and it will check the SHA-1 hash of your password against the published list of hacked hashes, and tell you whether you’re safe or not. Don’t understand what I’m talking about? Never mind. You soon will.
- Is it safe? Yes. It is an offline tool, and doesn’t connect to the internet in any way – especially not to publish your password, nor is it saved on the disk or added to the list.
- Don’t believe me? No problem – disconnect your internet connection while using it, then delete the application from your machine, before reconnecting to the internet.
- Still worried? Still no problem. I’ve published the sources. You can check what I do, and compile the checker yourself.
The hash-checker project is stored at http://hashchecker.codeplex.com. You can get both the binary and the source code there.
The list of compromised hashes can be found here.
- Run the tool (Icon added to your desktop – you can’t miss it).
- To check against the LinkedIn hacked hash list, just type your password and select the hash list file.
- Optionally, you may unhide the characters, decide not to pad, or change the number of characters padded.
- Press “Search”, and wait a bit. Hopefully, the result will be in green, like mine…
In case you’re wondering about the padding, the list has the first 5 characters zeroed so as not to expose the hashes completely. Pretty much like with credit-card hacks, they leave out the last 4-6 digits.
Here’s a screen shot of my self-testing:
I sincerely hope you’re in the clear. And that this is the entire list of compromised hashes…
Either way, take a deep breath, and move on. Time to discuss what happened.
What is a Hash, and What Happened to LinkedIn?
Okay, here’s a crash course of password management. First, in order to authenticate users, most sites store the unique user identifier (username, email address, etc.) in a database, with some form of password.
Plain Text Passwords
The most naïve (and dangerous – never do it like that) solution is to store the password in plain-text, i.e. unencrypted. What these sites do, when you log in, is send the user-name and password (often unencrypted) over the internet, to the site, and then compare the given password with the stored one. If they’re the same, the user authenticated.
The problem is, that if someone manages to hack into the site’s database, that person now has your credentials, and can impersonate you on the site.
That might not seem very harmful, especially if it is not an important site, and you didn’t give it any sensitive information like your Social Security Number, or banking credentials. Unfortunately, that is not true! Statistically speaking, most users reuse their usernames and passwords in multiple sites, including ones where sensitive information is stored!
This means that if you register with www.someunimportantsite.com, with your email address, and password 12345678, it is extremely likely that you used the same password when you registered with the email service, and with www.paypal.com, and many other sites as well.
Knowing this, a malicious hacker may crack someunimportantsite.com, and with the credentials he got there, try to log in and impersonate you on paypal.com! Congratulations – you have now lost money!
Hashes and Hashed Passwords
In order to protect the passwords, most sites that care about their users (and about malpractice lawsuits), will encrypt their users’ passwords in such a way that it is impossible to derive the password from them. These sites use a form of encryption that is based on a one-way encryption algorithm. Simply put, it is an algorithm that easily and deterministically transforms some plain-text input into an encrypted output, but no algorithm exists that can reverse the operation and derive the input, based on the encrypted output. This encrypted output is called a hash. Two commonly used algorithms are SHA-1 and MD-5. LinkedIn, by the way, use SHA-1.
What these sites do, when you log in, is to encrypt your input, and compare it to the stored encrypted password. If the encrypted input matches the encrypted password, you’ve authenticated.
Problem is, this isn’t good enough.
Rainbow Tables and Rainbow Attacks
As previously mentioned, while it is impossible to reverse a hash, and derive a password, it is easy to generate a hash based on some input. And the same input will always generate the same hash. A hacker will use a rainbow-table, a table that has known passwords and their hashes, to hack a site that stores hashed-passwords.
What the hacker does, is take a hash, look it up in the rainbow table, and if he finds it, he looks up the password that creates it. Congratulations, you’ve now been compromised.
This is what happened with LinkedIn. This is the danger you face.
What Should LinkedIn’s Developers Have Done?
I’ve got no problem with how LinkedIn dealt with the attack, after it happened. My grief is that this fiasco could have been prevented!
What Is a Salted Hash, and How Does it Protect Users?
The problem is that many people reuse passwords, and that many passwords are commonly used by different people: 12345, 1qaz!QAZ, any word in the dictionary, “p@ssw0rd”, and 1337-speak (you pseudo-hacker-cool-boys know who you are). They all appear in every respectable rainbow table.
If a site’s developer would add some random and unique characters to the password, the resulting hash would be vastly different from the hash of the same unsalted password. It would be vastly different from the same password hashed with a different salt.
In short, a salted hash defeats rainbow attacks, because the uniquely salted hash would never appear in it, and no two users would have the same hash, and no user would have the same hash in two different sites.
The great thing is that since the salt cannot be separated from the salted password, the salt doesn’t need to be secret! The site can safely store the salt alongside the salted hash, without fearing for the security.
I repeat – all the site’s developers need to do is create a salt (256 bits of random bytes will suffice) and then hash the password concatenated with the salt:
saltedHash = Algorithm.ComputeHash(password+randomBytes);
Finally, save the salted hash and the salt in the same record in the database.
That is what LinkedIn should have done!
What Can You Do?
Unfortunately, beyond writing your congressman, brow-beating your site’s developers, and boycotting unsafe sites, you can’t do anything about how the passwords are saved. You probably won’t even know how they manage your password until something bad happens and it gets published.
You can, however make sure not to use commonly used passwords, and not make sure that your accounts in sensitive sites have unique, strong passwords, that you don’t reuse.
A password manager tool (I paid for, and love AI RoboForm) can help you keep passwords without having to remember them, and can generate strong random passwords for you.
If this seems like too much work, use levels of security – have one password for unimportant sites, and another safer one for important sites, and a unique one for each extremely sensitive or money-related site (email service, bank, PayPal, etc.).
I hope this helped clear out the air around LinkedIn, hashes, salts, and your own safety.