But this naturally raises big concerns for web developers: if one of the largest social networks, with all of their engineers, could have a password security breach, how do I keep user passwords secure? Here’s How…
What went wrong?
First things first. LinkedIn did not store (and therefore could not make directly available) anyone’s raw/plain-text password. They hashed the password instead. This means that if you look at the hashed version, you can’t readily tell what the original value is. This is a Good Thing™.
But unfortunately that’s only half of what is needed to ensure reasonably secure password hashes. The other is known as a salt.
A password salt is a bit of extra data that changes the output of the hash function. This means you can hash the same password 20 different times, and use 20 different (securely generated) salts, and the hash output will be different every time. This is a good thing because it means that attackers can’t use the most common password-cracking technique known as a Rainbow Table Attack to discover what the original raw/plaintext value was.
Unfortunately, LinkedIn did not salt their end-user’s passwords. This means that any leaked passwords would be susceptible to Rainbow Table attacks, which are likely to crack most of the simpler passwords found.
An additional (although less severe) cause of concern is that Linked In used a hash algorithm known as SHA-1. SHA-1 has documented vulnerabilities, but in practice most SHA-1 hashed passwords (that use secure random salts) should be fine.
But SHA-1 is definitely not as not as secure as stronger hashing algorithms like SHA-256 or SHA-512 for example. By using a stronger hash algorithm, you can avoid SHA-1’s risks (minor as they may be) entirely.
Or they could have used Stormpath, instead of rolling their own.
Stormpath keeps passwords super-secure
Stormpath uses SHA-256 (or better) algorithms to hash passwords. Additionally, all password hashes use large, secure, randomly generated salts. But we go well beyond even this.
We add computation complexity to the hashing process, to make it computationally infeasible for any attacker to breach even a single password. We also use other techniques that further hash passwords, like computing digests of hashed-passwords with private securely derived keys, among other things. This means it would effectively take thousands of years of current computing power to crack even a single Stormpath-secured passsword.
If you use Stormpath for your own applications, you never have to worry about any of this yourself. Our REST APIs and SDKs mean you never have to even think about this stuff. Passwords stay safe so you don’t ever have to store them, greatly reducing the possibility that these problems could ever affect you or your applications.
Fortunately, LinkedIn has reported that they are aware of the issue, and I’m sure they’re scrambling to fix things as best as they can.
If you want Stormpath to protect your users’ passwords, sign up today!