Because it isn’t a controversy until it’s been suffixed with “-gate,” right?
On most websites – let’s use Facebook as an example – when you sign up and set a password, the site stores your password after one-way encrypting it – i.e., your password is encrypted in such a way that it’s virtually impossible for anyone (even Facebook itself) to decrypt it. What’s the use of storing a password that can’t be decrypted, you ask? Well, each time you log into Facebook in the future, it encrypts what you type into the password field, and checks whether this encrypted password matches the stored encrypted password from earlier. That way, Facebook never even knows what your password is – it only knows what your password looks like after it’s been encrypted.
The reason for this approach lies in security. Imagine if your password were not encrypted on Facebook, and someone hacked into Facebook’s database and got everyone’s usernames and passwords. She would be able to find your password. Chances are, you don’t have a different password for every site, so the hacker could use that same password to access your e-mail, bank accounts, social media profiles, and so forth, and wreak all manner of havoc on them. So Facebook stores your password after one-way encrypting it, so that even if a hacker did break into their database, all she would find is an encrypted password that she can’t break. To give you a sense of what an encrypted password looks like, here’s my password for Mobcart:
Good luck decrypting that.
“But didn’t LinkedIn store encrypted passwords?” you ask. Indeed they did, but the encryption they used was of the “unsalted” sort. An unsalted password can be (and in LinkedIn’s case, was) decrypted, while a salted encryption is more secure and basically impossible to decrypt. LinkedIn has been around a while, so when they first set up their database of users and passwords, they stored the passwords as unsalted encryptions, since that was the standard at the time. Since then, the standards have changed, and now it is considered best practice to use a salted encryption to store passwords.
So LinkedIn should have converted its database to salted passwords, right? The problem with that is that decrypting even an unsalted password is extraordinarily difficult and time-consuming (keep in mind that of the 6.5 million passwords leaked, only 300,000 have been decrypted as of June 6th). So, LinkedIn would have had to decrypt all 160+ million of its users’ passwords, then re-encrypt them with a salted encryption. Not exactly a job for LinkedIn’s summer interns. (In fact, I’m not even sure it’s possible to decrypt all their passwords; I’m not familiar enough with cryptography to say.)
Here’s what LinkedIn could have done to migrate to salted encryptions: every time a user with an unsalted password logs in, LinkedIn would encrypt the password the user enters with both an unsalted and a salted encryption. It would use the unsalted (i.e., older version) encryption to confirm the user entered the correct password, then save the salted encryption as the user’s “new” password. It would then flag that user as having migrated to the new encryption format, so that when that user logs in in the future, it will check the user’s password with the newer encryption mechanism rather than the older. That way, LinkedIn could have gradually and seamlessly migrated its entire user base to the new salted encryption mechanism, and all 6.5 million of those leaked passwords would still be safely encrypted.
Have any thoughts on this approach? Leave a note in the comments on why this would or wouldn’t have worked, or any other ideas on how LinkedIn (and other websites) can avoid this problem in the future.