> Genuine question: does hashing with algorithm B an existing hash computed with algorithm A solve anything at all ?
Absolutely. It solves by far the #1 threat against password hashes when they get leaked.
Algorithm A here is SHA-1, which is very fast to hash, which makes it completely terrible for password hashing -- when an attacker gets their hands on the hashes and salts, with a halfway decent GPU they can dictionary attack and recover even very long passwords in just a few hours, and then merrily use the same password get into the email account, because to a first approximation everyone is terrible about password re-use.
Algorithm B here is BCrypt, which is very very insanely slow to hash, so the same attacker would need years/decades to recover the passwords from the hashes.
HashAlgorithmB(HashAlgorithmA(input)) is dominated by Algorithm B's runtime, so it is equally very very insanely slow to dictionary attack the hashes.
> I mean, A’s hash collision issues will just be applicable as well into B’s space, right?
Sure. But the threat here isn't collision generation at all -- that's more of a PKI infrastructure concern.
Nobody is worried that the guys who have these SHA-1 hashes are going to sit around generating collisions -- that would be slow and stupid, the collision would only apply to other SHA-1-using websites that use the same salt. For this reason, nobody cares about password collisions for leaked password hashes.
They're just going to throw dictionaries + listed salts into a GPU and generate SHA-1s at a rate upwards of 68 billion per second on a cheap GeForce 1080, and quickly reverse the entire table. That gets them into every site the same password was used for, no matter the hash function.
This is how all of those leaked password DBs get generated, and this is why people say “don’t use SHA-1, use BCrypt for passwords” in the first place. It’s all about speed being bad, not collisions.
This is the threat BCrypting SHA-1s guards against.
> And I would go for rehashing at next login, and, after a while, identify and disable (no login possible) the legacy accounts with their deprecated hash, forcing users to change password at their next login (if it comes one day, that is).
You're still keeping easily-reversible hashes around for some period of time that cost users control of passwords if-and-when they leak before you wipe them. You can do better with zero downside. Get rid of them all immediately.
Absolutely. It solves by far the #1 threat against password hashes when they get leaked.
Algorithm A here is SHA-1, which is very fast to hash, which makes it completely terrible for password hashing -- when an attacker gets their hands on the hashes and salts, with a halfway decent GPU they can dictionary attack and recover even very long passwords in just a few hours, and then merrily use the same password get into the email account, because to a first approximation everyone is terrible about password re-use.
Algorithm B here is BCrypt, which is very very insanely slow to hash, so the same attacker would need years/decades to recover the passwords from the hashes.
HashAlgorithmB(HashAlgorithmA(input)) is dominated by Algorithm B's runtime, so it is equally very very insanely slow to dictionary attack the hashes.
> I mean, A’s hash collision issues will just be applicable as well into B’s space, right?
Sure. But the threat here isn't collision generation at all -- that's more of a PKI infrastructure concern.
Nobody is worried that the guys who have these SHA-1 hashes are going to sit around generating collisions -- that would be slow and stupid, the collision would only apply to other SHA-1-using websites that use the same salt. For this reason, nobody cares about password collisions for leaked password hashes.
They're just going to throw dictionaries + listed salts into a GPU and generate SHA-1s at a rate upwards of 68 billion per second on a cheap GeForce 1080, and quickly reverse the entire table. That gets them into every site the same password was used for, no matter the hash function.
This is how all of those leaked password DBs get generated, and this is why people say “don’t use SHA-1, use BCrypt for passwords” in the first place. It’s all about speed being bad, not collisions.
This is the threat BCrypting SHA-1s guards against.
> And I would go for rehashing at next login, and, after a while, identify and disable (no login possible) the legacy accounts with their deprecated hash, forcing users to change password at their next login (if it comes one day, that is).
You're still keeping easily-reversible hashes around for some period of time that cost users control of passwords if-and-when they leak before you wipe them. You can do better with zero downside. Get rid of them all immediately.