Is MD5 Still Safe to Use?

"Is MD5 safe?" gets answered badly in both directions. One camp says it is completely broken and any use is negligent; the other points out that it is still shipping in half the software they touch and nothing has caught fire. Both are describing something real, because MD5 lost one specific security property and retained another, and whether that matters depends entirely on whether someone is trying to attack you.

Here is the precise answer, which the rest of this post unpacks. MD5's collision resistance is comprehensively broken and has been for two decades. Its pre-image resistance is not practically broken — nobody can take a digest and produce a matching input. The result: MD5 is disqualified from every security role, and still fine for detecting accidental corruption. For the underlying properties this depends on, see The Complete Guide to Cryptographic Hashing.

The Two Properties, and Which One Fell

A cryptographic hash makes several promises. Two of them decide MD5's fate.

Pre-image resistance says that given a digest d, you cannot find any input m with hash(m) = d. This is the "one-way" property, and it is what people mean when they ask whether a hash can be reversed. For MD5, the best known theoretical pre-image attack sits around 2^123 operations — better than the 2^128 brute-force bound in the way that a locked door with a slightly worn hinge is better than one without, and entirely out of reach in practice.

Collision resistance says that you cannot find any pair m1 ≠ m2 with the same digest. Note who chooses the inputs: the attacker chooses both. That is a far weaker requirement to break, and the birthday bound already caps it at 2^64 for a 128-bit digest before any cryptanalysis. Real cryptanalysis dropped it much further.

This asymmetry is the whole story. An attacker cannot look at the MD5 of your password file and derive passwords. An attacker can absolutely produce two files that share an MD5 digest, hand you the harmless one, and later substitute the other.

The Timeline of the Break

• 1996 — Dobbertin finds collisions in MD5's compression function. Cryptographers begin recommending SHA-1 for new designs. This is the moment MD5 stopped being a defensible choice for anything new.
• 2004 — Wang and Yu publish a practical full-collision attack. Collisions go from theoretical to hours of computation.
• 2007 — Stevens, Lenstra, and de Weger demonstrate chosen-prefix collisions: the attacker picks two arbitrary, meaningfully different prefixes and computes suffixes that force both onto the same digest. This is the version with teeth, because the colliding files can be genuinely different documents rather than near-identical blobs.
• 2008 — A research team uses chosen-prefix collisions against an MD5-signing certificate authority to mint a rogue intermediate CA certificate. An abstract weakness becomes a demonstrated attack on the public web PKI.
• 2012 — The Flame malware uses an MD5 collision to forge a code-signing certificate and impersonate a vendor update service. Nation-state tooling, deployed in the wild.
• Today — A chosen-prefix MD5 collision runs in hours on a single machine, or minutes on rented GPUs, for a cost measured in single-digit dollars.

Twenty years and no reprieve. Nothing in that timeline is going to reverse.

What This Rules Out

Any use where the hash is expected to be evidence against a motivated party:

Digital signatures and certificates. Signature schemes sign the digest, so a collision lets an attacker move a legitimate signature onto a different document. The 2008 and 2012 incidents were exactly this.

Tamper detection and code integrity. If your build system, package manager, or file-integrity monitor decides "unchanged" by comparing MD5 sums, an attacker who can write the file can also make it collide. The check will pass and report nothing.

Deduplication of attacker-supplied content. If users upload files and you key storage on MD5, a user can upload a file that collides with someone else's and cause the wrong content to be served or overwritten. This has been demonstrated against real storage systems.

Password storage. MD5 fails here for an unrelated reason: it is fast. A commodity GPU computes tens of billions of MD5 digests per second, so unsalted MD5 password hashes fall to brute force and rainbow tables almost immediately. This was true before 2004 and remains the most common way MD5 shows up in a breach report.

Anything called a "security control" in an audit. NIST does not approve MD5 for cryptographic use. PCI DSS, FIPS, and most compliance regimes will flag it regardless of how you argue the threat model.

What Is Still Fine

The surviving uses share one feature: nobody is trying to fool you.

Verifying a download completed intact. Bit flips from a dropped packet or a bad cable do not conspire to produce a matching digest. If a mirror publishes only an MD5 and you check it, you have genuinely confirmed the bytes arrived whole. You just have not confirmed the mirror is honest.

Internal deduplication and content fingerprinting. Identifying duplicate rows, files, or blobs inside a system where all the content is yours.

Cache keys, shard selection, ETags. Any place the digest is just a fast, well-distributed identifier and a collision would be an inefficiency rather than a compromise.

Non-security file comparison. Confirming that two copies of a large directory tree match, on machines you control.

If the goal is purely accidental-corruption detection and you control both sides, MD5 is not even the natural choice — CRC32 Checksum Generator does that job faster with a 4-byte output. CRC32's much shorter output means it collides by chance far more often (roughly one in four billion), so it suits streaming and per-block checks rather than whole-file identity. Neither resists an attacker.

How to Decide in Thirty Seconds

Ask one question: could someone benefit from making two different inputs hash to the same value?

If yes — the file crosses a trust boundary, gets signed, gets served to users, or backs an authorization decision — MD5 is out. Use SHA-256. Compute it with the SHA-256 Hash Generator and compare digests exactly rather than by eye; the Hash Comparison & File Integrity Verifier exists precisely because humans skim long hex strings. How to Verify a File Checksum covers the full verification routine.

If no — it is a checksum inside a closed system with no attacker — MD5 is acceptable, and the MD5 Hash Generator is there when a legacy sum needs matching. Just write down which case you are in, because the note you leave is what prevents the next engineer from promoting a convenience checksum into a security control.

If You Are Migrating

Two practical notes. First, the digest width changes: MD5 is 32 hex characters, SHA-256 is 64. Database columns, log parsers, and fixed-format filenames all need widening. Second, do not double-hash. Wrapping MD5 in another MD5, or salting it, does not restore collision resistance — the collision is found in the input to the function, and it survives whatever you do afterward. Change the algorithm.

If you are deciding what to move to, MD5 vs SHA-256 covers the head-to-head, and SHA-256 vs SHA-512 covers the choice within the SHA-2 family once you get there.

The Verdict

MD5 is not safe, in the sense that matters most: it cannot resist an adversary. It is also not reversible, so the panic about MD5 digests leaking their inputs is misplaced — the real password risk is speed, not reversibility. Treat MD5 as a corruption detector and nothing more. The moment your threat model includes a person rather than a cosmic ray, it belongs on the other side of the line.