4 ms·
That's why I mentioned "a few rounds of it". Use 1000 if you're paranoid, you can make it as computationally complex as BCrypt. And, of course, you should use s
by olegkikin 9y ago
That's why I mentioned "a few rounds of it". Use 1000 if you're paranoid, you can make it as computationally complex as BCrypt. And, of course, you should use salts. Good luck breaking that. You couldn't even break my double MD5.
Another thing you should do is not allow common or short passwords. That includes "password123". That alone will immediately elevate your security.
> Additionally, if I can find a bit of text that hashes the same I don't care what the original password was. I have a key that works
And you clearly don't understand how the collusion vulnerability works. You can't create one with a given hash. You carefully craft two documents that hash to the same hash, which you don't know in advance. Again, you can prove me wrong by doing just that to the hash in the code snippet.
- tedunangst 9y ago1000 rounds of MD5 is nowhere close to enough. Don't use MD5 for password hashing.
- stouset 9y agoFFS, stop making cryptographic recommendations to others when you don't have expertise in this area. Cryptographers nowadays are recommending PKBDF2 (essentially iterated hashing with the hash algorithm of your choice) with at least 100,000 rounds. And it's considered to by far the weakest of "modern" password hashing approaches, behind bcrypt, scrypt, and Argon2 (in that order). Your double-MD5 is garbage, and nobody is going to bother wasting their time breaking it because it's a bullshit challenge. If you used a strong, unique password, you've missed the point, because users in the real world don't. If you used a weak password, we have a few billion points of empirical data that contradict you, so why bother installing hashcat and mucking about with password cracking rules when anyone paying attention for the past ten years knows what the outcome is going to be?
- olegkikin 9y agoSo use 100,000 rounds, use 1 million rounds, whatever amount makes you happy. You guys can't even break 2 rounds. I actually do use PKBDF2 / Bcrypt in real world projects. My original comment was entirely about MD5 not really being broken, just too fast. > because users in the real world don't. No, you missed the point, and I wrote about it specifically. You should not allow weak / common / short passwords.
- stouset 9y agoMD5 is broken for passwords because it is too fast. Sure, if you use PBKDF2-MD5 with a random salt and 100k iterations you're going to be fine but that's not what anyone in this thread, including you, has been talking about. You started off saying MD5 is fine, then backed off to saying it's fine with a salt, then fine with two rounds, then suggested 1,000 is okay, now we're at 100,000. At what point do you stop making excuses and acknowledge that your original advice was garbage, and backpedaling repeatedly is not helping your case? Further, it is impossible to categorically prevent weak passwords. You can impose length restrictions. You can disallow common passwords. You can require special characters. But people's ability to come up with weak, pattern-based passwords fundamentally outperforms our ability to stop them, and at some point restrictions become so burdensome that people stop signing up for your app altogether. "Just block weak passwords" is ridiculous on its face and you either know it and are arguing simply to save face, or you don't know it and are infuriatingly overconfident for your level of incompetence. I'm past the point of caring which.
- astrodust 9y agoA thousand rounds of MD5 is absolute insanity, I mean that's the sort of thing that gets you banned from ever writing security critical code ever again. The cost of an MD5 cycle is basically zero. Zero times a thousand is still zero. Zero times a million is zero. It's got zero value in terms of protection. Even SHA1, which is a much harder hash to compute, can be processed at trillions of hashes per second on some hardware. If you did a million cycles of SHA1, guess what? That thing can still crack a million guesses per second. Bcrypt has a difficulty number you can pin at a level that's uncomfortably high. It may take 200ms to verify a password if you really crank it. That means you can't do thousands of hashes per second, but you're stuck doing maybe a thousand hashes per minute. You can't dictionary attack that. I know how the collision vulnerability works. People have been creating MD5 collisions for fun for a while now, unconcerned with the original hash. If they focused their effort on matching hashes, they could probably do it by exploiting fundamental weaknesses in the MD5 hash system itself. At this point a sufficiently robust SAT solver can probably crack it. All your hand-waving about disallowing easy passwords doesn't matter. If you add restrictions, people find ways around them. It also doesn't matter if you make passwords incrementally harder if someone can crack them easily. Their computer doesn't care if they set it to search ten characters instead of eight, modern crackers are pretty efficient to fairly intimidating lengths.
- olegkikin 9y ago> The cost of an MD5 cycle is basically zero. Zero times a thousand is still zero. Zero times a million is zero. I don't think you have any clue what you're talking about. Do a million sequential rounds of MD5 on your CPU and measure how long it takes. I guarantee you, it's not zero. Not even close.
- astrodust 9y agoGPU accelerated MD5 is a thing and I assure you it's a lot closer to zero than you'd think. High-end FPGAs can smash through SHA1 at rates of billions per second and MD5 is not even that complicated. A million rounds is not as hard as Bcrypt cranked up to a sufficiently robust level.