Last week, as by know, no doubt, you have probably read, LinkedIn had a security breach, with 6.5 million passwords being stolen. It has caused a lot of people to argue back and forth that they didn’t implement good enough security measures and should have done things differently, such as using a salted SHA-1 hashing algorithm instead of an unsalted hash as they had used.

However, I found a really interesting interview with Thomas H Ptacek on the Krebson Security news site.

Ptacek maintains that no matter whether they had used salted or unsalted SHA-1 encryption, or even SHA-512 encryption, it would not have mattered. The problem lies not with how secure the hashing is, but rather how quickly the hash is calculated, making brute force attacks possible.

Ptacek goes on to explain how these cryptographic hashing techniques are designed to be as fast as possible, allowing many millions of attempts to crack the passwords in a reasonable amount of time, which is exactly what happened when the hashes of the LinkedIn passwords were stolen.

The solution that should have been using is password hashing. The key difference with password hashing is that it takes a lot longer – from milliseconds to a second or more – to hash the password (or any other value passed to it), which makes a brute force attack such as those that would work on a normal cryptographic hash virtually impossible. One common way of accomplishing this is to simply apply a cryptographic hash repeatedly, say a thousand times, on the value. With no increase in development cost, and with only a slight increase in server load for logging in users, it is possible to eliminate the threat of brute force attacks on password hashes.

So, why wasn’t it implemented this way in the first place then? Well, simply, most programmers do not know about it, myself included. The vast majority of programmers spend very little time analysing hashing techniques, relying instead on accepted practices to provide guidelines as to how to implement security.

As an example of this, 2 days ago, I wrote (and passed) the Microsoft Certified Technical Specialist module Accessing Data with .NET 4, which covers just about everything you need to know about manipulating data with .NET. There is a section in the module specifically covering how to protect passwords in a database, with the recommendations of the book being that you should use salted SHA-1 hashing, or if you want better security SHA-512. Nowhere in the book is any mention made of password hashing techniques such as discussed by Ptacek in the interview mentioned above.

Therefore, is it any wonder that most programmers are oblivious to the dangers when even official sources fail to mention the best way to protect your data, instead of methods that have time and again proven to be relatively easy to compromise.

Share