Needs more salt, but more importantly, needs more rounds

Like many people, I use LinkedIn to maintain connections in my professional world. So, when the recent news of the security breach at LinkedIn came out, I poked around a little bit.   Interestingly enough, my long, random password's hash does not appear in the leaked password hash file.  Despite this fact, I changed my password just to be safe.

As far as LinkedIn goes, I am somewhat disappointed.

I've seen lots of comments in the news lately regarding the fact that the password hashes were unsalted. The thing is, I don't think that this was the biggest problem here.  Sure, salt is important, but....

In a recent project that I have been working on, I've been playing around with "Eksblowfish" (link and link).  The more I've played around with Eksblowfish over the past few months, the more enamored I've become with it. Here is a password hashing scheme that really gets things right -- it is a hashing algorithm that...over time...can be configured to keep in step with rapid increases in CPU power.

I'm not the only person who thinks this way either.  Check this out.

I use certain hashing algorithms in some of the protocol work that I sometimes work on.  When I'm working on protocol stuff, the hashing algorithms that I select for my work are algorithms that are more designed for speed.  The protocols that I design always always always have to be fast, efficient and secure.

However, a hashing algorithm designed for speed is not really a good choice for a password hashing algorithm.  In the case of a password hashing algorithm, the criteria is less on speed but instead more on defending against some jerk who happens to have stolen your user's hashes.  Situations like this might be inevitable ; I don't know.  However, what I do know is that if/when this happens, you might as well make it really really difficult for the jerks to mount a dictionary attack against your site's stolen password hashes.

The staff at LinkedIn should definitely consider putting in place a scheme that migrates newer password changes on their site to Eksblowfish hashes...and...while they're at it, they should make sure that they're specifying a number of "rounds" that ensures that future attackers will have a really hard time if they manage to (again) steal the password hashes.