Tuesday Top Tip - Slow Password Hashing

Like Slow Cooking, Slow Password hashing seems to be in vogue at the moment, using hashing algorithms such as bcrypt or PBKDF2. Troy Hunt has a mega in-depth look at the subject on his blog,  with an emphasis on asp.net. This comes after recent incidents such as with LinkedIn and eHarmony.

So the general recommendation would seem to be that for new projects you should consider using a slow password hashing algorithm to protect your users' passwords. I say "consider using" because there is a performance overhead associated with using these approaches which you need to be aware of.

However.....

It's also worth remembering that if you end up in a situation where you are praying that a slow hashing algorithm will protect passwords and save you, then you have other BIGGER problems.

To get at your well hashed passwords in the first place, an attacker will likely have hacked your database anyway and gotten at the other information held in the database: names, addresses etc. This is the bigger issue. Somehow, hackers get access to the LinkedIn password table in the first place.

So before embarking on a major exercise to introduce slow password hashing, it's worth spending time ensuring that the baddies can't get at the password table in the first place. 

Useful Links

• Troy Hunt: Our password hashing has no clothes  
• 365 days of Slow Cooking
• BBC:LinkedIn passwords leaked by hackers
• CNET: Analysis: eHarmony had several password security fails

Social: del.icio.us DiggIt! Reddit Stumble Google Bookmarks Technorati Slashdot