In the wake of the leak of their password database, LinkedIn issued a blog post: An Update On Taking Steps To Protect Our Members, wherein they claim they had an existing project to salt the passwords, and that that "transition was completed prior to news of the password theft".
That cannot be true. The transition could not have been "completed". One cannot "transition" a bashed password to a salted properly hashed password. The original plaintext password is required to generate the salted and properly hashed data.
Best case, LinkedIn was in the process of slowly migrating accounts over, like so: When a user logs in, look in the new salted hash database. If there is no entry, then use the old unsalted hash to verify the user, then compute the new salted hash, store that, then delete the old unsalted one.
Doing it this way has the disadvantage that it doesn't protect the people who haven't yet logged in, and there are a LOT of LinkedIn users who log in to update their profile only occasionally, such as when they change jobs.
It does have the "advantage" that it's invisible, allowing a slow migration "on the down low".
However, I'm not hugely impressed.
Mmm, wouldn't this work;
ReplyDeletesha1(unsalted_password_hash + ":" + salt)
and then
sha1(sha1(password) + ":" + salt)
for subsequent password checks? I can't poke a hole in that quickly, and it'd allow you to hash the entire db without waiting for users to supply the original password.
They should have sent out a mass password reset notice and disabled login access until an account goes through that process. Anyway, people just do a password reset request when they can't log in anyway, so even if people missed the memo they would still go through the process eventually.
ReplyDeleteAll salting achieves is to make the hashes of the same password for different users appear differently -- i.e. you can no longer target the "most popular passwords" when brute forcing. It provides no protection against the brute forcing itself. So it helps, but not as much as people think it helps.
ReplyDeleteUsing a hash algorithm that isn't designed to be "as fast as possible" is the current best way to slow down brute forcing to "unreasonable" levels, and carefully implemented can allow you to 'improve' your existing stored credentials in place. Bcrypt is a good example of this.
http://codahale.com/how-to-safely-store-a-password/ is a good start for references on bcrypt.