One of the big mysteries of Friday’s LivingSocial breach announcement was an understanding of what password hash algorithm they used. Well according to an updated FAQ pointed out by Dan Goodin in his ArsTechnica article, LivingSocial had used SHA1 with a 40 byte salt. Not bad…
The FAQ also noted that LivingSocial upgraded to bcrypt to take advantage of a true computational intensive Password-Based Key Derivation Function (PBKDF). This switch is great news and I hope other websites take note and upgrade BEFORE a breach.
Q: What kind of protections do you use to protect my password and how does it work?
A: LivingSocial never stores passwords in plain text. LivingSocial passwords were hashed with SHA1 using a random 40 byte salt. What this means is that our system took the passwords entered by customers and used an algorithm to change them into a unique data string (essentially creating a unique data fingerprint) – that’s the “hash”. To add an additional layer of protection, the “salt” elongates the password and adds complexity. We have switched our hashing algorithm from SHA1 to bcrypt.
But why bcrypt and not scrypt, which would add a memory-hard component to bcrypt’s increased computational difficulty? I mean if you are going to upgrade your algorithm, wouldn’t you want to choose the strongest at the time of the switch?
And of course there is concern regarding the true effectiveness of scrypt per one of our earlier posts where Dan “@dakami” Kaminsky observed “At the point where scrypt gets strong enough to really inconvenience brute forcers, it seems to help DoS’ers #” as part of a Twitter conversation.
Why do you think LivingSocial chose to use bcrypt over scrypt? Let us know in the comments below. Today’s post pic is from xqus.com. See ya!