Is MD5 considered insecure?

  • After all these articles circulating online about md5 exploits, I am considering switching to another hash algorithm. As far as I know it's always been the algorithm of choice among numerous DBAs. Is it that much of a benefit to use MD5 instead of (SHA1, SHA256, SHA384, SHA512), or is it pure performance issue?

    What other hash do you recommend (taking into consideration data-bound applications as the platform)? I'm using salted hashes currently (MD5 salted hashes). Please consider both md5 file hashes and password hashes alike.

    You mentioned salted hashes, does that mean you're talking about password hashing? Password hashing requires different properties from normal hashing, which makes SHA-256 almost as bad as MD5 in this context.

    I'm using md5 hash to check for critical files integrity before loading them, and salted md5 hashes for passwords.

    Neither is good choice, but for completely different reasons.

    like how much bad, i need to fully understand the situation before recoding the whole part, its a bloody 24 hours at minimum. the code base is like 2K

    You probably want to read How to securely hash passwords. I think it's one of the most important questions on this site.

  • MD5 for passwords

    Using salted md5 for passwords is a bad idea. Not because of MD5's cryptographic weaknesses, but because it's fast. This means that an attacker can try billions of candidate passwords per second on a single GPU.

    What you should use are deliberately slow hash constructions, such as scrypt, bcrypt and PBKDF2. Simple salted SHA-2 is not good enough because, like most general purpose hashes, it's fast. Check out How to securely hash passwords? for details on what you should use.

    MD5 for file integrity

    Using MD5 for file integrity may or may not be a practical problem, depending on your exact usage scenario.

    The attacks against MD5 are collision attacks, not pre-image attacks. This means an attacker can produce two files with the same hash, if he has control over both of them. But he can't match the hash of an existing file he didn't influence.

    I don't know if the attacks applies to your application, but personally I'd start migrating even if you think it doesn't. It's far too easy to overlook something. Better safe than sorry.

    The best solution in this context is SHA-2 (SHA-256) for now. Once SHA-3 gets standardized it will be a good choice too.

    the numbers are rather scary, hashcat can try up to [86.24M combination/s] on 8 threads win 7 64bit (md5 hash), it's like a new era of password cracking at the loose. nice answer...

    @sarepta hashcat is harmless compared to ocl-hashcat which runs on a GPU. A single GPU can to over 6 billion combinations per second with that.

    A pre-image attack is theoretically possible against MD5, current attacks have a computational complexity of 2^123.4 for full pre-image though.

    Keep in mind that *partial* pre-image attacks are possible with MD5. You can take an existing file and alter metadata / append junk and generate a collision against a file you generate entirely. That's how the MD5 SSL certificate collision attack works.

    @ewanm89 - 2^123.4 is infeasible (even with billions of GPUs calculating billions of MD5 hashes per second for billions of years). Yes its better than 2^128 by a factor of 24, but the distinction is meaningless for real attacks. (But agree with other reasons to avoid MD5).

    @Polynomial I wouldn't call that a partial pre-image. It's rather something like a structured collision.

    @CodesInChaos Yeah, that's probably a better description. It was about 7am when I wrote that!

    @drjimbob I didn't say it was feasible yet, though we are getting there, I just pointed out it exists, and that was a full pre-image attack. As others have pointed out, partial pre-image is often good enough. At our current rate with GPU and and FPGA hardware accelerating bruteforce and still getting faster all the time it probably won't be all that long before full pre-image becomes feasible.

    @sarepta My GPU can handle ~279.5M combinations a second for SHA1 and it's a couple of years old now. I hate to think what a nice shiny new GPU can do for the faster MD5...

    Using GPUs you can get 33.1Billion hashes a second for MD5. 6 char passwords are instantly toast.

    The authors of the Flame malware managed to generate a chosen-prefix collision in MD5 which is quite scary, I wouldn't recommend this algorithm for any purpose anymore. SHA-3 is standardized by now AFAIK.

    @buherator I don't think SHA-3 is standardized yet. We know that keccak is the winner of the competition, but we don't know which tweaks NIST will apply to it before it becomes SHA-3. Concerning the insecurity of MD5, not every application relies on collision resistance, so not every application needs to urgently migrate away from MD5. For new projects I certainly wouldn't recommend MD5.

    I've seen this reasoning (about speed of md5) a number of times, and while I agree that slower hashing is more secure, I don't understand the practical advice against salting. So, I am salting strings with 20 chars salt, the resulting string is at least 28 chars. Now, an attacker can do billions of hashes per second per GPU, let's say he has millions of GPUs running for an year. What is the chance he will get the original string? I can do math, the probability is practically 0.

    @ivan A salt is stored alongside the password hash and thus known to the attacker. Password hashing is only the last level defense when an attacker has compromised the server all its secrets (including encryption keys used to encrypt the password hash, or pepper).

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM