Cloud Security: All Your Passwords are Belong to Us

A couple days ago, Ars Technica published an article with the ominous title, “25-GPU cluster cracks every standard Windows password in <6 hours.” We knew things have been heading this direction for a long time, but that’s a pucker-factor 11 in the cloud security world. Basically, given access to the password hashes, every Windows system is inherently insecure (yea, yea, I know that’s a redundant statement, but play along with me). The upshot is, with a few commodity GPUs and a little bit of clustering software to drive them efficiently in parallel, you can try every single possible Windows password in six hours. This is not a theoretical attack limited to large governments; this is something a high school computer club could put together with bake-sale money. Ars Technica writes:

The five-server system uses a relatively new package of virtualization software that harnesses the power of 25 AMD Radeon graphics cards. It achieves the 350 billion-guess-per-second speed when cracking password hashes generated by the NTLM cryptographic algorithm that Microsoft has included in every version of Windows since Server 2003. As a result, it can try an astounding 958combinations in just 5.5 hours, enough to brute force every possible eight-character password containing upper- and lower-case letters, digits, and symbols. Such password policies are common in many enterprise settings. The same passwords protected by Microsoft’s LM algorithm—which many organizations enable for compatibility with older Windows versions—will fall in just six minutes.

“No biggie,” I hear you say. “NTLM is known to be horrible and so we don’t use it.” Not so fast.

First, let’s lay the groundwork. For security, most systems store passwords in a hashed format, rather than in-the-clear. If somebody manages to steal the password file, all they get are the hashes and would then be forced to brute-force guess each of the passwords.

But (and this is a big but) there are two types of hash functions that are used in the world, fast hash functions and slow hash functions. Fast hash functions are buit for speed (duh!) and are required were throughput is an issue. For instance, the IPSec security protocols allow you to compute a hash function for each packet to prevent tampering. The hash is attached to the packet and is recomputed at the receiving end and compared. Since this function is directly in the performance path (every network packet!) it needs to be as fast as possible. Hash functions like MD5 are often used in these applications. SHA1, which is tremendously slower than MD5, is slower but also used often because it’s more secure.

Unfortunately, these fast hash functions also used by mistake by application programmers to store passwords. Unlike IPSec, with a password hash, there is no need for speed. A user logs in, the hash is computed, and then a security token is provided to the user for all subsequent interactions until the user logs out again. An algorithm like MD5 can achieve hashing rates of hundreds of MB per second, but the average number of simultaneous logins at even a fairly large web property (not Google or Facebook) is close to one. Even an algorithm that is 100 times slower than MD5 is unlikely to be a performance problem for password hash computations.

By using a fast hash function to compute password hashes, programmers are making it easy for crackers to brute force their way into the system. See the difference between the performance results between the fast and slow hash functions on the last couple pages of the presentation describing the cracking hardware from the Passwords^12 Security Conference. The old NTLM algorithm is woefully insecure and also quite fast, allowing the cracking hardware to compute 348 billion per second. MD5 is far more secure but still delivers 180 billion per second. SHA1 is still more secure but clocks in at a quite fast 63 billion per second.

Now, contrast that with the slow hash performance shown on the next-to-last-page. In particular, note that bcrypt (05) achieves “just” 71 thousand per second on this hardware. That’s several orders of magnitude slower than MD5 or even SHA1. In fact, bcrypt was intentionally built to be slow to help thwart brute-force attacks of this type. No, you would never want to use bcrypt for IPSec; it would be horrible for that. But it works great for hashing passwords.

If the thought of achieving only 71 thousand hashes per second scares you, go measure the actual login rate of your application or web property. Unless you’re working at one of the mega properties like Google or Facebook, you have nothing to be worried about. Even if you’re lucky enough to have 71 thousand users all login at the exact same moment, you’ll only delay their login by a single second. But you’ll thwart brute-force cracking machines like this if your password database should ever fall into the wrong hands. And if you think that’s unlikely, go talk to the folks at LinkedIn.

Why is this important for Leverhawk readers? Because more and more applications are making their way into the cloud. While cloud security is something people worry about more than a real issue, we are providing more attack vectors to our adversaries. Rather than trying to create absolutely unbreachable access to password hashes, we need to rely on algorithmic security. Ideally, even if our password hash file fell into enemy hands, we could rest secure that night knowing that it would take an attacker a long time (at least decades) before they could breach even a single passsword. Bcrypt delivers this and is built to be tunable, allowing application programmers to slow it down even more as cracking technology gets faster.

So, as Coda Hale says, “How to safely store a password. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt.” With all the application libraries available, there is no reason not to do it by default.

Speak Your Mind