Understanding the LinkedIn Security Breach
Last week LinkedIn suffered a major security breach where millions of “hashed” passwords were leaked. Dan Pinnington wrote an excellent post last week outlining how you can tell if your LinkedIn password has been compromised.
This security breach has prompted many to reset their password at LinkedIn and other sites. However, as Dan points out, you shouldn’t reset your password to a password you use at other sites. Why? The LinkedIn password leak gives us a perfect case study.
What was leaked at LinkedIn was not your exact password, but rather a hash of your password. A hash is a one-way mathematical function that maps one piece of data to another representation of the data in a deterministic, repeatable way. A commonly-used hash function in security applications is the SHA-1 function; the SHA-1 hash of a password, such as “testpassword” would be as follows:
Original Text: testpassword
SHA-1(‘testpassword’) = 8bb6118f8fd6935ad0876a3be34a717d32708ffd
In this case, LinkedIn would store the SHA1 hash of your password in its password database rather than the original text. Each time you log into LinkedIn, it will take the password you entered, apply the SHA-1 hash function, and compare the result to the SHA-1 hash of your password stored in the database; if they match, you’re logged into your LinkedIn account.
If the LinkedIn password database was leaked, the idea was that the impact of such a leak would be limited as only the SHA-1 hash of the password would have been leaked. Since the hash function is a one-way hash function, it is theoretically impossible to recover the original text given only the SHA-1 hash of the original text.
However, a simple SHA-1 hash of a password is vulnerable to attack via a rainbow table. Whereas normally a brute force attack to identify a SHA-1 password would take days or weeks, a rainbow table attack makes most passwords recoverable almost instantaneously. To combat this form of attack, best practice is to “salt” the password with a random number prior to computing the SHA-1 hash; this added randomness renders rainbow tables and other brute-force attacks ineffective. LinkedIn, however, overlooked this security best practice, and stored its passwords without any salt.
Now, with that nerdy aside out of the way, what take-home lessons have we garnered from the LinkedIn security breach? Do not use the same password across multiple websites. Even if the website is run by a huge, publicly traded company, such as LinkedIn, it may not be storing your password data in a secure fashion. By using a unique password for every website, you guarantee the impact of a password leak will be contained the greatest degree possible.
To make managing your various logins easier, use a password manager such as 1Password.
Thanks for raising another interesting tech issue on Slaw.
A couple of additions/caveats:
1) Best practice would be to not only salt passwords prior to hashing but to use a hash which has been purposefully designed to be computationally slow to increase the time required to build rainbow tables or carry out brute-force attacks. SHA-1 is a fast, efficient hash which was primarily intended for use in digital signing-to authenticate the uniqueness/integrity of data (such as hashing a hard drive and an image thereof to verify that the image is identical to the original and neither has been altered). SHA-1 still serves this purpose well. However, SHA-1’s speed makes it a poor choice for hashing user passwords for storage. Hashes such as bcrypt have been designed specifically for password hashing. Bcrypt has salting built in and it can be made more computationally demanding (slower) on purpose to provide the desired balance between system resource use and resilience against cracking.
2) While random salts can and do add randomness to a password, the key benefit salts provide against cracking is not randomness but increased length of passwords and uniqueness of the hashes in the database, even if 10 or 100 users have the same password (not uncommon when sites get into the millions of users). For example, each instance of the password ‘12345’ would have the same hash in the case of an unsalted password database so an attacker would only have to crack this hash once to know the password ‘12345’ was used by all users who shared that identical password hash. Whereas, when salted with a unique value prior to hashing, each instance of the password ‘12345’ would generate a unique hash value that would have to be cracked individually only to learn that it was yet another instance of ‘12345’.
3) While salting does generally render rainbow tables and brute-force attacks much less effective. It will not render them ineffective in all cases. For example, in a targeted attack against one or a few hashes of specific users, bruteforcing may remain entirely feasible depending on the hash function used, password length, salt length, character set of the password+salt and resources/time the attacker is willing to invest. Also, in a situation where an application forces users to use a weak password by restricting length and/or valid characters (think 4-digit PIN), adding a 32-bit salt (4 characters) is only going to give you a total length of 8 characters, well within reach of a nearly instantaneous rainbow table attack for common hashes like SHA-1. Of course, we would hope that anyone bothering to use salts is going to also enforce reasonable password strength rules, but this is not always the case. Salting is just one more security control that, when implemented correctly and layered with others, will effectively lower the risk of breached passwords being cracked before accounts can be secured.