Monday 11 June 2012

More Than One Type of Hash

Oh No Not Again

Why does it seem that we still continue to read about millions of passwords / user credentials being stolen on such a regular basis, almost a quarter century after that famous and oft-cited Unix password security study? This past week has seen three separate large scale breach scares at LinkedIneHarmony and Last.fm. Users are being told to change their passwords immediately.

But that only protects the service provider against intrusion and accusations of laxity. On its own it does nothing to protect the user, whose new password can presumably be obtained just as readily, and whose old one may well be tied to more sensitive accounts e.g. at their bank or on line shopping stores. And more specifically in cases such as these, why is there so much panic anyway over the theft of password hashes, i.e. the encrypted versions of the users' passwords, rather than the passwords themselves? Aren't these hashes supposed to be designed for safe transmission in the clear?

Monkey Wrench

Yes and no. And mostly, no. The crucial point here is the distinction between a cryptographic hash and a password hash. The former is designed to be applied to content. As such, it carries a core requirement of fast decryption. Lightning fast in fact, as in: every IP packet arriving at a node must be decrypted quickly and on-the-fly, so as to generate no discernible latency to router traffic. Password hashes start from the exactly opposite requirement: maximal difficulty of decryption.

It matters little to a typical website user if their daily log in takes a full tenth of a second to authenticate. It matters a lot more to an attacker, who must try billions or trillions of alternatives to achieve a single successful break in. So it's not just a case of choosing between MD5 (feeble), SHA-1 (better, but still broken) and SHA-512/384 (no known collision attacks), or of adding a little salt. To arrive at a secure password hash, typically you would first select your atomic encryption algorithm, and then apply it a few thousand times.

Must Try Harder

So why do most providers use a cryptographic hash to do the job of a password hash? Most of the time this is allowed to happen because the developers in charge of a site's security are general practitioners, rather than security specialists. To them, any tool with encryption in its name is as good as any other.

This is a general problem of a lack of knowledge in the field. Developers have been successfully dissuaded from building their own cryptographic systems, being taught instead to rely on proven off-the-shelf solutions. And that's undeniably a great deal of progress, given the potential scope for devastating errors. Now, this community needs also to learn that different kinds of cryptographic solutions are available, for different jobs.

For a more extensive treatment of this subject, see Brian Krebs's recent interview with Matasano Security researcher Thomas H. Ptacek: http://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/.

2 comments:

  1. INTERESTING. But I don't understand why you would need to apply SHA-512 + SALT a few thousand times. I thought that SHA-512 + SALT would generate a hash so secure that no rainbow table could hack within a few million years?!

    ReplyDelete
  2. Never mind, I get it, read the link in your article. 5 stars!

    ReplyDelete