Technology is confusing but encryption and the mysterious world of hacking exist on a whole other level. It’s Matrix-like tech voodoo.
Hackers are a 21st-century boogeyman. They possess incomprehensible powers, ninja-like access to any digital domain they choose. They can outsmart your cleverest developer. If a hacker wants your company’s data, you are powerless to stop it. Right?
Probably, yes (sorry, this post isn’t about reassurances). But that’s not the lesson of the LinkedIn debacle.
(this is an abbreviated cross post from my own µ-Dev blog. See the original post for more of the techie specifics)
LinkedIn was hacked. It happens. But the encoded passwords that the hackers posted revealed something much more disconcerting: LinkedIn’s password encryption was awful. Borderline criminally negligent, in fact.
I’ll do my best to keep the techie stuff to a bare minimum here. But I want you to be able to appreciate at a visceral oh-god-that’s-awful level just how bad their security was.
And let me preface this by saying that I’m not a security expert. I’m a developer-turned-entrepreneur who had to google “encryption best practices” to figure out how to secure user passwords for my company, EssayTagger.com. In all honesty, I’d call myself a security novice. But after ten minutes of surfing the web I developed a better security policy than LinkedIn did. That’s pathetic.
It turns out that password security is actually fairly straightforward. There are just a handful of best practices to follow. Unfortunately LinkedIn only followed the first one.
Password Best Practice #1: Don’t store the user’s password.
Instead of storing your password directly, any sane site will store a gobbledygook encoded version of your password:
91dfd9ddb4198affc5c194cd8ce6d338fde470e2 = “mypassword”
The hacker can’t just read your password, even if he gets access to the database. Yay!
However, the encoding used is completely standard. So all the hacker has to do is compile a list of common passwords ("password", "password1234", "pass1234", etc), compute the encoding for each one, and just do a simple compare. As soon as one of his gobbledygook encoded results matches your gobbledygook, he knows your password. What’s worse, every user that used the same password you did has the exact same gobbledygook. So you’ve all been compromised in one fell swoop.
This process is so simple that a human can do it by hand if he really wanted to. That’s awful security. This is the level of security LinkedIn used.
Can you blame someone for not being a security super-ninja?
No. But you don’t need to be a ninja to do better than this.
Here's how:
Password Best Practice #2: Use a random salt to produce unique hashes.
A “salt” (no clue why it’s called this) is simply extra random text that is added to your password. Instead of encoding “mypassword” the site will encode “mypassword/2dsdjkl23r”. Notice the different result:
91dfd9ddb4198affc5c194cd8ce6d338fde470e2 = “mypassword”
eb8b3a04fb5bb65ecc02f40e83fa4d8065b26af6 = “mypassword/2dsdjkl23r”
And every user gets her own random salt. So all of the fools who used the weak “mypassword” will end up with different gobbledygook. So even if one “mypassword” account is compromised, the other “mypassword” fools are still safe, for now. Better.
But even this isn’t perfect.
It turns out that the salts have to be stored out in the open, unencrypted (sounds odd, but it’s actually pretty logical; you can google it to find out why).
The hacker can see your salt so all he has to do is take it into account when he encodes his list of common passwords. From there it's the same process of simply searching for gobbledygook matches.
But because your salt is different from everyone else's none of his computations are relevant for anyone else's account. He’ll have to recompute his entire list of common passwords for every single account. That’s an order of magnitude more work. Good!
But we can make it even more painful for the hacker:
Password Best Practice #3: Iterate. Like, a lot.
Here’s a cool fact about the encoding algorithm: it can encode its own output over and over again. This is a powerful tool. Let's salt and encode our weak password:
eb8b3a04fb5bb65ecc02f40e83fa4d8065b26af6 = “mypassword/2dsdjkl23r”
Now let's the run that resulting gobbledygook through the encoder again. This time we get:
21925d1ea52fb44f65d8f71bb69ce5c1eadb61a4
We can keep doing this as many times as we like. Security folks recommend a minimum of 1,000 iterations!! A modern computer can rock these iterations in a matter of milliseconds. No big, but now you’ve made life really difficult for the hacker. He has no way of knowing if you did 10 iterations or 1,000 or 50,000. So now he has no choice but to compute each of his common passwords over thousands of iterations, just to see if he gets a match. And all that work still only applies to your account because of your salt. Cracking the next password forces him to do all those computations all over again from scratch.
This is now getting excruciatingly computationally intensive for your hacker. He can still do it, but it’ll take him a crap-ton of time to crack all 6.5 million passwords this way. The sun might supernova before he’s done. No joke.
That is good security. That’s what I implemented for EssayTagger. And I know these best practices because I spent a whopping ten minutes on Google.
LinkedIn didn’t salt their passwords and they iterated exactly once.
Conclusions and lessons learned
Now do you see why LinkedIn’s password fiasco is so horrifying? Remember that LinkedIn’s paltry encryption could be hacked by a human by hand! But just add a salt and a couple thousand iterations and now a supercomputer cranking until the end of the Earth’s existence might not be able to crack all 6.5 million passwords in time. That difference in security would have cost LinkedIn all of a couple milliseconds of compute time per login. Trivial compared to the immense security boost they would have achieved.
The shocker isn’t that LinkedIn was hacked. No, the shocker is that they were so careless with our passwords and failed to follow basic encryption best practices.
What you should do
Go figure out which of your developers coded the password encryption for your company and ask: “Are our passwords salted and how many times are we iterating the hashing function?”
If he says, “uh, what?”, you have a problem that you need to address ASAP.
Further reading
The resource I relied on to guide my password security policy:
https://www.jasypt.org/howtoencryptuserpasswords.html
A similar, but even harsher take on LinkedIn and, now, eHarmony's password security:
