On the Twitters security journalist @briankrebs called last week “breach week” with the recent password/hash dumps of LinkedIn, eHarmony, and Last.FM. Of course the big advice from a consumer perspective was to change you passwords immediately. And those of us that had a little bit of tech curiosity could check if our password had been cracked through sites like LeakedIn.org or just doing it on our own.
From a backend perspective, there was unanimous “best practice” advice for LinkedIn and others to use salted password hashes to stymie pre-computation attacks such as with rainbow tables. Of course LinkedIn noted that a portion of their database already used salted password hashes as part of a “recent” update. I wonder how “recent” that update was … probably right after they learned of this breach and before it hit the news.
Anyway, I was a bit stumped after reading @johnwilander tweet – “Salting password hashes is not best practice. It’s standard practice. #” What more could you do? I guess keeping the salts separate from the password hashes and more secured would help. But you could almost consider that security-through-obscurity. So the question remains … what is best practice?
To answer this question I was fortunate enough to run across an interesting article over on F-Secure’s blog noted by @mikko that pulled up a post from last year they wrote as part of a response to the HBGary Federal kerfuffle. In it they recommended not just applying the short-term fix of adding salts but instead implementing a more complex key derivation function (KDF). In the article they noted that simply adding a salt wouldn’t offer as much security as most would expect. The problem is that most hash algorithms are designed to be computationally really fast. Given the speed of modern hardware and even a single beefy graphics card, the article noted that an attacker could easily crack a password in less than a month. Add in a few more graphics cards to the machine and then replicate that box a few times and attackers could brute force that same password in almost no time.
KDFs vary but their most important property relies on the fact that they require multiple hashing iterations to combat the computational efficiency of most hashing algorithms. Another property that some add include necessitating a unique number of iterations per user. Add these two properties to the above “standard practice” of requiring a unique salt for each user and you drastically increase the difficulty of the cracking passwords. The other interesting property of KDFs is that as computational speed increases, KDFs-derived passwords can continue to be protected by simply augmenting the number of required hashing iterations. This practice is similar to how RSA regularly increases their recommended key bit length.
Now none of this is new… As part of their PKCS series RSA provided one solution known as PBKDR2 way back in 2000. It was even published as an IETF recommendation. Although the algorithm remains fairly strong, experts have discovered a few chinks in its armor and other KDFs have appeared. One is bcrypt and then even that was improved upon with the introduction of scrypt. None of these KDF recommendations are bullet-proof however they are all significant improvements over simple salted password hashes.
LinkedIn, eHarmony, Last.FM and any other online companies would be in their right mind if instead of just applying a band-aide by shaking salt on the problem right now, they should rather implement one of the above KDF schemes as a more permanent solution.
Updated 2:00 PM: Here’s another interesting article that describes why developers are often reluctant to implement any of these KDF in their software. Basically, they’re afraid it will slow things down too much.
What do you think? Do you see any issues with replacing standard password hashing with KDFs? Let us know in the comments below. Today’s post pic is from PCMag.com. See ya!