Brute forcing md5 is easier than some other hashing algo because of collisions?
(And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)
Brute forcing md5 is easier than some other hashing algo because of collisions?
(And I would disagree that knowing that how to properly hash passwords means that the whole framework itself is poorly designed)
The point is it's achievable. If someone gets a dump of the database it can be turned back in to usable accounts. If you use something much slower they can't. There's no benefit to using MD5. On the other hand, using a better hashing algorithm protects user's passwords from brute force attacks. Why wouldn't you want that?
Quite a good article about cracking a well designed database of bcrypt'd passwords - http://arstechnica.com/security/2015/08/cracking-all-hacked-...
Point taken. Use SHA-? instead of MD5.
SHA family, including the rather unrelated but exceptionally nifty SHA-3 (Keccak), are still hash functions and are still really fast to compute (good if you need to verify the contents of something, bad if you need to store secure information). A decent GPU can still crack SHA hashes effortlessly, and a dedicated attacker will have some good FPGAs (in which case you'll be cracked in hours). Use a function that is meant for storing passwords.
[0] http://security.stackexchange.com/questions/38134/what-are-r...
Making password checking slower is very easy if the cracker doesn't have local access. Just sleep for XXX ms at every hash check and double it for every incorrect attempt (per IP).