This week, a number of high-traffic sites had security breaches, including LinkedIn. Over 6 million accounts were compromised. Their customers’ login info showing up on hacker download sites. A high profile asset like LinkedIn is bound to be a target. The fact the bad guys got in is not that extraordinary. Given a high-enough reward, hackers can be a determined bunch.
The fact LinkedIn got breached does not mean anyone was necessarily asleep at the wheel. They got unlucky in a cat-and-mouse game. However, the low level of effort LinkedIn put into securing their customers passwords is extraordinary! This was a grad-level stuff up. Developers at LinkedIn should be embarrassed.
Always one for worrying about appearances, my marketing guy asked how secure our customer passwords are. Handling credit cards and online purchases is core to our business, so we take storing customer data seriously. Here is a crash course in password storage.
For the really lazy (read “irresponsible”), passwords can be stored un-encrypted (known as “in clear text”). Its not worth going over why this is a bad choice. Generally, passwords are stored after being scrambled using a “one-way hash function”. These are well known and mathematically proven algorithms that are good at scrambling passwords.
If you used the password “secret” at LinkedIn (yes, some people did!) the scrambled (hashed) version was:
When users change their password, the scrambled (hashed) version is stored and checked next time they log in. Each user that used “secret” as their password had the above string stored with their username, not the actual password.
Using this approach, there’s no need to ever store the user’s actual password. If a hacker gets into your database, all they find is a scrambled sequence of characters and not the real password.
The key property that makes this work is one-way hash functions cannot be reversed (hence “one-way”). There is no good way to take the scrambled data and write a program that unscrambles it to generate the original password.
Using hashes like this, developers can say:
- We never store the users password unencrypted
- We use a one-way hash that is industry standard and cannot be reversed
Sounds secure! This is where it seems the linkedin.com guys stopped their password protection.
The trouble is, hackers are resourceful and have been at this for years. While programs that unscramble hashed passwords are hard, its easy to write a different type of program. By taking a dictionary, hashing every word in it and saving the results into a database, the hackers job is now trivial. Not only is this possible, but its been done and such databases and programs are readily available. They’re called rainbow tables.
Now, with the scrambled passwords, all the hackers need to do is look up the rainbow table and find the original password. Programs to do this are really, really fast! As many people use common words for their passwords, this is a great way to breach a good percentage of users accounts. As LinkedIn have just found out!
Needs More Salt
While users can protect themselves by using strong passwords, website developers can also take a very simple step to make rainbow attacks futile.
Instead of just scrambling the user’s password, like “secret”, a long random number can be added to the password before it’s hashed. With a different random number for every account, even users who have the same password, the scrambled versions (the ones saved in the database) will be different from each other.
Now, if the hacker looks up hashed password in their rainbow tables, they won’t find a match.
Salted passwords will not stop a determined hacker getting access to a prized asset. A top quality dead-lock on your front door will not stop a thief from breaking a window to get in. But salted passwords are so simple to do, there is no reason not to. Just like you don’t go on vacation and leave the front door open. Unless your PR department needs the extra work explaining the unexplainable, make sure you’re doing a better job with your passwords than basic hashing.
What you can do as a product owner
There is no reason not to use salted password hashes. Its literally a few hours work to add a random number to your customers’ passwords before saving the hash to the DB. Just look at how fast LinkedIn were able to respond! If you want to give the hackers a harder time, you can run hash function a number of times. Its fast to execute, the user won’t notice a second or two increase in login and it defeats rainbow table attacks.
What you can do as a user
Don’t use the same password for all your accounts. At the very least, have different passwords for different types of accounts. For example, if you use the same password for all social networks, make sure you use a different password for your work email. And a different one again for you internet banking and PayPal.
Back in 1998, I was doing some work for the Australian and US governments around single processing. We had a few guys from the US here and I remember a particular conversation about security. It as a discussion about the merits perimeter vs multi-level security. Perimeter security fortifies the external walls and concentrates all effort making it as hard as possible for someone to break in. Multi-level security takes it as given that a penetration will happen and each system and information store needs to take localized and reasonable precautions to securing its own critical data.
The conversation with my US counterpart was intense but brief. The risk of having the outer defences breached vs the effort of taking reasonable precautions at every level make the economics simple. Secure all the way down was the obvious way to go.
A decade and a half later, after countless high-profile breaches, its pretty clear that relying on a “hard” exterior with “soft” interiors leads to one breach being catastrophic. Like a house of cards tumbling down, hackers cannot believe their luck when they get in and find easy pickings. Looks like LinkedIn are still learning.