Avoiding Heartbleed

The newly-disclosed Heartbleed vulnerability is particularly painful. Attackers can use a malformed heartbeat message to elicit a memory dump from vulnerable servers (those running code based on OpenSSL 1.0.1 through 1.0.1f). This dump can include confidential data such as bank data, credit card numbers, PINs, passwords, private keys, and many other things. Whatever’s in the memory of the vulnerable process may be leaked.

Administrators and product developers are rushing to find and upgrade vulnerable software then regenerate the servers’ private keys and force their users to reset their passwords. Because the Heartbleed vulnerability can be exploited without detection, we’ll all be wondering for months what data might have been stolen while the servers were vulnerable.

How can we avoid such problems in the future? Certainly, we can try to reduce the number of bugs in our software. Reducing bugs is essential but we can never get the number of bugs to zero. Recognizing that all software has bugs, we should all be moving from reusable passwords to dual-factor authentication and/or cryptographic keys stored in hardware. Why?

• Reusable passwords are really dangerous. Users can’t remember long passwords so they choose short passwords or reuse the same password across many services. Short passwords are easily guessed by attackers using automated tools. Reusing a password across many services means that if any of those services is compromised, the attacker gets access to all of your accounts. Heartbleed is just one of ten thousand ways that your password can end up in the attacker’s hands. Once they have it, they can access your email, bank account, documents, etc.

• Dual-factor authentication helps. If one factor is compromised through whatever technique, the other factor can be a fallback. The stronger and more independent each factor is, the better. Two passwords isn’t much more secure than one. One password entered on a web site and a confirmation text from a mobile phone is better.

• Cryptographic authentication is generally considered the gold standard because it can be made arbitrarily strong, no reusable credentials are employed, and ease of use is great.

SSL servers authenticate themselves using asymmetric cryptography. Generally, this is quite secure. However, each server must protect its private key against disclosure. Many servers don’t do this well, storing their private key in memory where it can be stolen using Heartbleed and many other attacks. Instead, servers should always keep their private key in hardware so that it can’t fall into the wrong hands.

So the best way to protect against attacks like Heartbleed is to continue reducing software bugs. And the best way to reduce the impact of such attacks (since they are inevitable) is to move to cryptographic authentication with the private key stored in hardware. The Trusted Platform Module (TPM) is the best place to store a private key on a client device like a PC or mobile phone. On a large server, a Hardware Security Module (HSM) will provide the cryptographic acceleration needed to handle many simultaneous users.