Hacker News Reader

Comment by jgrahamc | Hacker News Reader

Is there a cryptanalytic reason why a company that has a database full of MD5/SHA1 hashes can't perform a one time upgrade by computing bcrypt(salt, the_old_hash) for every hash they have in the database and then when someone logs in do bcrypt(salt, md5/sha1(password)) to check the password?

View on HN

That's a perfectly reasonable approach — we did that at PBworks a long time ago. Totally transparent to users if done right. You can also declare password bankruptcy and zero out everything. That forces password resets for your entire user base. The latter approach doesn't go over so well with users or support staff but it is much simpler.

That's what I did when I migrated our application to bcrypt some time ago.

I had some questions about whether using an md5sum as the bcrypt input, with much less keyspace (only hex characters) had any impact on security but nobody could/would answer.

I'm guessing that knowing that the plaintext for the bcrypt hash is always going to be 16 characters of 0-9,a-f might have some impact on crypto analysis but considering the passwords most people use I'm guessing it's only going to be a net win in terms of entropy.

Yeah sure, bcrypt(salt, md5/sha1(password)) is in general less "secure" than bcrypt(salt,password)#, it's still more secure than md5/sha1(password).

# Note though, that you need at least 20 printable ascii chars to get the 128 bits of entropy possible in an MD5 hash, so for _most_ passwords, you could optimize your cracker by only bruteforcing bcrypt(salt, md5/sha1(password)) using shorter strings as password guesses rather then needing to bruteforce the whole 128 bit MD5 space. With bcrypt and salt though, that turns into an "only practical for state-level attacker" I think.

Only for users with >128/160-bits of entropy in their password, which probably means your password is well over 20 chars long.

It looks like that is what LinkedIn claims to have done.

http://blog.linkedin.com/2012/06/06/linkedin-member-password...

"...which includes hashing and salting of our current password databases."

Does this mean before this leak, they didn't hash/salt passwords?

Yes, all the passwords in LinkedIn's massive leak were unsalted.

The auth.getMobileSession method in the 2.0 API, and the scrobble 1.0 API were both sticking points.

I've been wondering the same thing myself recently. I know of a number of legacy systems that could do with this but I'm unsure of how cryptographically safe it is (bcrypting md5. Would love if someone with knowledge in the area could confirm that it's ok.

per-user salt.

Reply on news.ycombinator.com