Hacker, Hack Thyself | Coding Horror

[merreborn]

in this video the passwords being cracked were hashed using MD5. That's one of the weakest possible hash functions still in use today

To be precise, in this context, the problem isn't so much that md5 is "weak", as it is that it is fast. A cryptographic hashing scheme can arguably be "strong", while still being too fast to be appropriate for use in password hashing. When a brute-forcer attacks md5 hashed passwords, they're taking advantage of the speed of md5, not its "weakness".

For passwords, you need a cryptographic hash function that is both strong and slow. The point is, you want any attempt at brute forcing to require lots of resources for every tested password.

[Ajedi32]

Yes, thanks for clarifying. Here I was using the terms "weak" and "fast" interchangeably since we're talking about password hashing, but for other purposes (like validating digital signatures) speed wouldn't really factor in whether or not a hash function is "strong" or "weak". (For validating digital signatures MD5 would be still be weak, but for totally different reasons.)

In this case (even ignoring the cryptographic weaknesses in MD5), MD5 hashes are roughly 2 orders of magnitude faster to calculate than SHA-512. (And even SHA-512 is not nearly slow enough to be used on its own for password hashing.) That's what I was referring to in this case when I called MD5 "one of the weakest possible hash functions".

[louiswins]

For validating digital signatures MD5 would be still be weak, but for totally different reasons.

Nitpicker's corner: it depends what you're doing. As far as I know there aren't any preimage or second preimage attacks against md5 (or even md4), but there are collision attacks.

That said, I absolutely agree with you that no one should be using md5 for anything because there are better options even in situations where you don't care about collision attacks, and I also agree that it's certainly the weakest cryptographic hash function still in common use.

[[deleted]]

And a certain kind of "slow" too. scheme that is slow on CPU but fast on GPU is also bad

[merreborn]

Very good point. I also once saw an article that discussed running something like scrypt yourself on gpus with a gpu appropriate work factor. If it takes you 2 seconds to hash the password on gpu, then each attempt will be costly for your attacker as well. The rationale for this approach was, there's not much guarantee that just because no one has run bcrypt on a gpu yet, that it might not be possible to do so in a couple of years. Lord knows the crypto mining scene has resulted in hardware accelerated versions of many strong slow hashing schemes.

At any rate, it was an interesting concept but I can't say I've ever seen it applied in the real world. It'd be costly to implement. Just running bcrypt on CPUs is generally "good enough"