A quick guess as to the cause would be lazy rehashing after enough developers complained about using md5 to hash passwords. They don’t generate the bcrypt hash until that user logs in; so if an account is abandoned, the old md5 hash will stick around forever.
What they probably should have done if this was the scenario was hash the md5 to keep it non-reversible, but I guess I can understand either not thinking it was a serious issue or not wanting to rehash their entire dataset with an extremely expensive hash function.
I don’t think that’s right. The problem wasn’t that md5 was used to store passwords, per se. The problem was that your cookie, or similar, was being generated as md5(password). There’s no reason it couldn’t have been random, but md5(some stuff) looks pretty random too. Actually, it has the nice property that you don’t need to garbage collect stale tokens since there’s only one, and even better, changing your password automatically logs out all other sessions. The implications of storing the password hash in a second database column were then overlooked.
not wanting to rehash their entire dataset with an extremely expensive hash function.
While I assume it was simply a lazy programmer, a simple loop with a sleep 1 in it should have been low impact enough that the expense wasnt so big. It will take a while, but so what?
Original link, which is somewhat buried: http://cynosureprime.blogspot.com/2015/09/how-we-cracked-millions-of-ashley.html
…
…
well…
A quick guess as to the cause would be lazy rehashing after enough developers complained about using md5 to hash passwords. They don’t generate the bcrypt hash until that user logs in; so if an account is abandoned, the old md5 hash will stick around forever.
What they probably should have done if this was the scenario was hash the md5 to keep it non-reversible, but I guess I can understand either not thinking it was a serious issue or not wanting to rehash their entire dataset with an extremely expensive hash function.
I don’t think that’s right. The problem wasn’t that md5 was used to store passwords, per se. The problem was that your cookie, or similar, was being generated as md5(password). There’s no reason it couldn’t have been random, but md5(some stuff) looks pretty random too. Actually, it has the nice property that you don’t need to garbage collect stale tokens since there’s only one, and even better, changing your password automatically logs out all other sessions. The implications of storing the password hash in a second database column were then overlooked.
While I assume it was simply a lazy programmer, a simple loop with a sleep 1 in it should have been low impact enough that the expense wasnt so big. It will take a while, but so what?
I’ve said it before and I’ll say it again, if a random number will suffice, use a random number, not some crazy crypto or hash thingy.