Why MD5 Is Broken but Still Everywhere

Figure 1: Two different inputs can share one MD5 digest

The hash that refuses to die

MD5 shows up everywhere, in download checksums, legacy databases, cache keys and old code, decades after cryptographers declared it unsafe. The confusion is that it is broken for some jobs and perfectly fine for others. Treat it the wrong way and you open a real hole; understand the line and MD5 still has honest uses.

Here is what broke, what it means in practice, and where the function is still acceptable.

What "broken" actually means

A hash promises a few properties, and MD5 has lost the one that matters most for security: collision resistance. A collision is two different inputs that produce the identical digest. For a sound hash this should be infeasible to find. For MD5 it is trivial.

It helps to separate two ideas. A preimage attack, recovering the input from a digest, is still hard for MD5. A collision, crafting two inputs that match, is easy. Most dangerous MD5 misuse turns on that second failure.

How broken: collisions in seconds

The first practical collision landed in 2004, and the techniques have only sharpened since. Today a laptop can produce two different files with the same MD5 in under a second. That is not a distant theoretical risk; it is a command you can run.

Once collisions are cheap, any system that trusts an MD5 digest to prove two things are the same can be fooled by an attacker who prepared both.

Where it already bit the real world

This is not hypothetical:

• In 2008, researchers forged a trusted certificate authority by abusing MD5 in certificate signatures, which let them mint certificates for any site.
• In 2012, the Flame malware used an MD5 collision to fake a Microsoft code-signing certificate and spread while looking legitimate.

Both attacks worked because something security-critical trusted MD5 to be collision resistant, and it was not.

What MD5 is still fine for

The function is fast and still useful wherever no attacker is trying to trick you:

• Non-security checksums that catch accidental corruption in a download or transfer.
• Deduplication and cache keys, where you only need a quick fingerprint of benign data.
• Bloom filters and sharding, which care about even spread, not secrecy.

For these, speed is a feature and nobody gains by forcing a collision. Our file checksum tool computes MD5 alongside stronger options for exactly this kind of quick integrity check.

What you must never use it for

Stop using MD5 the moment an adversary benefits from a collision or a guess:

• Digital signatures and certificates, the exact ground where it already failed.
• File integrity against tampering, where an attacker can prepare a matching file.
• Password storage, because MD5 is fast and unsalted, so a value like 5f4dcc3b5aa765d61d8327deb882cf99 sits in every rainbow table. Use a slow, salted algorithm instead, as our bcrypt tool does.

For general hashing where you want a modern digest, reach for SHA-256.

A worked example

Plain MD5 values are quick to see:

md5("")         = d41d8cd98f00b204e9800998ecf8427e
md5("password") = 5f4dcc3b5aa765d61d8327deb882cf99
md5("hello")    = 5d41402abc4b2a76b9719d911017c592

Those look fine, and for a corruption check they are. The danger is invisible here: an attacker can build a second, different input that produces one of these same digests. When your security depends on that being impossible, MD5 has already lost.

The takeaway

MD5 is broken for anything where someone might force a collision, which rules out signatures, certificates, tamper protection, and passwords. It stays acceptable as a fast checksum for accidental errors on data nobody is attacking. Keep that line clear: quick integrity, yes; trust or secrecy, never. For those, move to SHA-256 or a proper password hash.