The loss of passwords by LinkedIn, eHarmony, and Last.FM should be a wakeup call for CIOs, security auditors, and IT security professionals everywhere. Let’s take a look at what probably happened, what you can do, and why you need to look beyond passwords on your own systems.

One-way hashes are used in many places in your applications for data protection, data verification, and integrity checking. It is one of those fundamental building blocks of security. There are standards for hash algorithms and conscientious security professionals will be sure that a system uses industry standard hash methods such as those recommended by the National Institute of Standards and Technology (NIST). The Secure Hash Algorithm (SHA) is one of those standards and is readily available in a variety of open source and commercial applications (we have one). It is a common practice to save passwords as hashes rather than saving the password in the clear or encrypted. (You could, of course, protect passwords with encryption and good key management, but that is a discussion for another day).

LinkedIn was using SHA-1 for their password hash. So what went wrong?

First, SHA-1 is no longer recommended for use in security systems. It has been replaced by a new family of stronger and more secure SHA methods with names like SHA-256, SHA-512, and so forth. These newer hash methods provide better protection from the type of attack that LinkedIn experienced. We use SHA-256 or strong methods in all of our applications. So using an older, weaker algorithm that is no longer recommended was the first problem.

Second, it is considered a security best practice to use a Salt value with any data that you are protecting with a hash method. What is Salt? In the context of hashes a Salt value is just some additional data that you add to the sensitive data you want to protect (a password in this case) to make it harder for an attacker to use a brute force attack to recover information. LinkedIn was not using a Salt value with passwords, and more simple passwords were easily recovered. (More on Salt in a moment). The attackers easily recovered LinkedIn passwords.

LinkedIn has apparently taken some steps to better protect their passwords. Is it enough? Let’s look at what should be done. This will help you look at your own Web and IT systems and understand where you have weaknesses.

These are all common recommendations from the security community:

Recommendation 1 – Use industry standard, strong hash methods

You should be using SHA-256 or SHA-512 for this type of data protection.  Do not use weaker versions of the SHA hash method, and do not use older methods like MD5. Do not be swayed by arguments that hash methods consume too much CPU power – just ask LinkedIn if that is their concern right now!

Recommendation 2 – Use NIST certified hash software libraries

If you use a hash method to protect sensitive data, you should use a NIST-certified software library. Why? Because it is terribly easy to make mistakes in the software implementation of a SHA hash method.  NIST certification is not a guarantee, but in my mind it is a minimum requirement that you should expect. I find it curious that most people would not consider buying a used car without a CARFAX report, but completely ignore NIST certification when deploying hash software to protect sensitive data. A lot more is at stake, and you don’t even have to pay to verify certification!

Recommendation 3 – Always use Salt with your hash

Always use a Salt value when creating a hash of sensitive data. This is particularly important if the sensitive data is short like a password, social security number, or credit card. A Salt value can make it much more difficult to attack the hashed value and recover the original data.

Recommendation 4 – Use a strong Salt value

Never use a weak Salt value when creating a hash. For example, don’t use a birth date, name, or other information that might be easy to guess, or discover from other sources (attackers are great data aggregators!). I recommend using a random number generated by a cryptographically secure software library or HSM. It should be at least 4 bytes in length, and preferably 8 bytes or longer.

Recommendation 5 – Protect the Salt value

Protect the Salt value as you would any sensitive cryptographic material. Never store the Salt in the clear on the same system with the sensitive data.  For the Salt value, consider using a strong encryption key stored on a key management system that is itself NIST certified to the FIPS 140-2 standard.

Are your systems at risk?

You are probably using hash methods in many places in your own applications. Here are some thoughts on where you can start looking to uncover potential problems with hash implementations:

• Passwords (obviously)
• Encryption key management
• System logs
• Tokenization solutions
• VPNs
• Web and web service applications
• Messaging and IPC mechanisms

Hopefully this will give you some ideas on what questions to ask, what to look for, and where to look for possible problems on your own systems. You don’t want to be the next LinkedIn, eHarmony, or Last.FM. They are not having fun right now! 

Download our podcast "How LinkedIn Could Have Avoided a Breach" to hear even more about my take on this breach and ways you can keep this from happening to your organization.

Patrick