> Curious to know if there are downsides to this (performance is an obvious one) or whether you're weakening the stronger hash by hashing a weaker one?
You're weakening the stronger hash by hashing the weaker one. The two main problems of MD5 are entropy (128-bit maximum) and collisions (because of lack of entropy).
By always hashing to MD5, you are losing the entropy of the stronger hashing algorithm.
Re:Security Issue February 2019: FAQ
by mystickphoenix on Friday February 15, 2019 @12:24PM
(#19172752)
Confirms a suspicion I had that it might be an issue. I assume it's a problem whenever you hash a weaker with a stronger, not just MD5 in particular.
Thanks!
Re:Security Issue February 2019: FAQ
by Dylan16807 on Friday February 15, 2019 @10:04PM
(#19176776)
It does cap it at 128 bits, but it is not an issue. 128 bits of entropy is plenty.
Had a thought on this, but I'm no security expert so if someone else could weigh in, that'd be awesome. Couldn't you just add a layer to the password hashing?
I.e., you start with MD5 because that's the best at the current point in history. Bcrypt comes around and you want to do a migration of all your users, so you take the stored MD5 hashes and run them through bcrpyt. Making sure, of course, that your login system does the same, MD5 followed by bcrypt. When the next-gen hashing algorithm comes around, you do the same, now the path is MD5->bcrypt->next-gen.
That way you're relying on the strongest algorithm "wrapping" the weaker one(s) without having to make everyone login again to generate the new hashes to be stored.
Curious to know if there are downsides to this (performance is an obvious one) or whether you're weakening the stronger hash by hashing a weaker one?