Is MD5 still safe to use?

Two numbers decide almost every MD5 question. Making two different files that share one MD5 takes about a second on a laptop. Making a file that matches the digest of a file somebody else already built is still beyond everyone, and no published result comes near changing that.

Those two numbers are the ruling. MD5 remains completely reliable for catching accidental damage — a copy that stopped halfway, a sector going soft, a link dropping bits — because damage cannot aim at a digest. It is unsafe the moment the person who built the file gains something from a second file that carries the same digest. The property MD5 lost is collision resistance, and it lost it in 2004; the properties that keep the first half of this paragraph true are untouched. MD5 vs SHA-256 sets the two functions side by side; this page is about deciding what to do with the MD5 you already have.

The rest of this page is an inventory: every job MD5 is actually doing in working systems, with a verdict and the reason for it; then the second way MD5 fails, which has nothing to do with collisions and gets the wrong fix applied to it more often than the first; then what a migration costs in the cases where it costs anything at all.

The question that decides it: who chose the bytes?

A cryptographic hash makes three separate promises, and MD5 has broken exactly one. Keeping them apart is the difference between a decision and a superstition.

Collision resistance is the promise that nobody can find two different inputs with the same digest while choosing both of them freely. That is the one that is gone. An identical-prefix MD5 collision takes about a second on an ordinary laptop, and the more dangerous chosen-prefix variety — where the attacker writes two documents that differ however they like and arranges for the digests to agree anyway — takes hours of commodity GPU time rather than a research budget.

Preimage resistance is the promise that a digest on its own tells you nothing about how to produce a matching input. Second-preimage resistance is the narrower promise that a file handed to you cannot be swapped for a different one carrying the digest you already hold. Both of those are still standing. The best published preimage attack shaves a few bits off brute force — roughly 2 to the power of 123 instead of 2 to the power of 128 — which is a paper result rather than a method, and neither number is reachable.

That asymmetry is the whole ruling, and it has a consequence people find counterintuitive: an attacker who intercepts a file an honest publisher built cannot substitute a malicious version and keep the MD5, because that requires a second preimage. The realistic MD5 attack needs the attacker to have made both files — which means it reaches you when the publisher is the adversary, when the publisher's build machine has been compromised, or when your system accepts files from strangers and treats matching digests as proof of sameness.

Accidental corruption, meanwhile, cannot aim. A dropped packet or a dying sector has no way of landing on a matching 128-bit value; the odds are roughly one in 2 to the power of 128, which is zero for every purpose you will ever have. This is why the 32-character value under a vendor's download link is still worth checking, and the limits of what it tells you are in what a digest proves about tampering.

Where MD5 shows up, and the verdict on each

Three of those rows deserve a sentence more than the table gives them.

The deduplication row is the one that catches working systems. A storage service that decides two uploads are the same file because their MD5s match has handed an attacker a lever: prepare a harmless file and a hostile one that collide, upload the harmless one, wait for it to be reviewed, then upload the hostile one and have the service quietly serve the copy it already holds — or the other way round, depending on which side of the deduplication you sit. The same hazard applies to any cache that keys untrusted content by MD5. Among your own files none of this exists, which is why finding duplicates by hash is a perfectly reasonable use of a broken function.

The malware blocklist row is worth understanding because it is so often cited as evidence that MD5 is fine. It is fine there, but the reason has nothing to do with collisions: a hash-based blocklist catches only samples it has seen before, and any attacker can defeat it by changing one byte regardless of which algorithm you use. Switching that list to SHA-256 improves nothing, which is a useful reminder that not every MD5 in a codebase is a finding.

The certificate row is history rather than advice. Browsers and certificate authorities stopped accepting MD5 signatures years ago, so this is not a decision you are able to make badly any more. It is on the list because it is the clearest demonstration of the attack: in 2008 researchers used a chosen-prefix collision to obtain a certificate that a real authority had signed and that they could then use to sign anything they liked.

The second way MD5 fails, and it is not collisions

If the MD5 you are worried about is in a password column, everything above is irrelevant. The problem there is not that two inputs can be made to collide; it is that MD5 is cheap. A single modern GPU works through billions of MD5 guesses a second, which means a dictionary, a list of leaked passwords and an afternoon recover most of a table. Unsalted digests are worse still, because the same password produces the same 32 characters for every user and the whole column can be looked up at once — which is all the sites advertising “MD5 decryption” are actually doing.

Keeping these two failures apart matters in practice, because they call for different fixes and people regularly apply the wrong one. A manifest that compares MD5s needs a stronger hash. A password column needs a different kind of function. Moving the password column to SHA-256 looks like progress on a ticket and changes nothing at all.

What replacing it actually costs

Less than people assume, and on a Mac it is often free in both directions. The old argument for MD5 was speed, and that argument has inverted: Apple Silicon accelerates SHA-256 in hardware and does nothing for MD5, so the supposedly heavier algorithm finishes roughly three times sooner — around 2 GB/s against well under one. Switching a batch job from MD5 to SHA-256 on a modern Mac makes it faster. Producing an MD5 on a Mac covers the mechanics if you still need both.

Where it genuinely costs something:

• Values already in circulation. Every MD5 you have published, and every one a customer wrote down, keeps its meaning only if you keep publishing it. Publish both during a transition rather than swapping one for the other.
• Fixed-width storage. A column sized for 32 characters does not hold 64, and a schema change touches everything that reads it. This is the most common reason a migration stalls.
• The other end of an integration. If a partner's system only accepts MD5, your choice is their roadmap, and the right move is to say plainly what the digest is and is not proving in the meantime.

One rule outranks all of them: never change the algorithm behind an existing value without labeling it. An unlabeled 32-character field that quietly becomes 64 characters breaks every consumer at once, and an unlabeled digest is a support ticket waiting to happen — exporting a manifest shows the format that names the algorithm for you.

Troubleshooting

The audit says MD5 must go and nothing uses it for security

You are probably right and you will probably lose the argument anyway. MD5 has never been on NIST's list of approved hash functions, so frameworks that reference that list flag every occurrence without regard to what it is doing, and an auditor is not authorized to accept your threat model instead. Switching a cache key to SHA-256 usually costs one line and removes the finding permanently, which is almost always cheaper than writing the exception document. Save the argument for the case where the migration is genuinely expensive, and document the use rather than the algorithm.

Our system compares the MD5 and the file size together

That does not help. The colliding pairs people construct are the same length as each other by construction — the attack works by substituting blocks, not by adding them — so every famous example of two files sharing an MD5 also shares a byte count. Size is a useful sanity check against a truncated download and no defense at all against a crafted one.

We only have MD5s for a ten-year-old archive

Keep them and use them. If you created the archive, the old MD5s still do their job: they tell you whether the bytes have changed since you recorded them, because nobody can build a replacement file matching a digest of a file you made. What you should do is record SHA-256 values now, alongside the MD5s, so the next decade is covered. Both digests come out of one read of each file in Rocket Hash, so the recompute costs a single pass over the archive rather than two, and verifying a backup covers the rest of the job.

A vendor will not publish anything but an MD5

Check it anyway, and be precise about what you have learned: the file you hold is the file that page described, and the page is exactly as trustworthy as it was before you started. Get the download over HTTPS from the canonical host, ask them for a SHA-256, and if the software is something you install widely, treat the absence of a signature as the real finding rather than the choice of algorithm.

Two files have the same MD5 and I need to know if they are identical

Hash both with SHA-256 and compare those instead. If the SHA-256 values also agree, the files are identical and you have found a duplicate rather than an attack; if they disagree while the MD5s match, you are holding a constructed pair and should want to know where it came from. Dropping both files into the File vs. File comparison gets you the same answer as a sentence, and the line under the seal names the algorithm it compared with — comparing two files walks through it.

Frequently asked questions

What is collision resistance, and why does losing it matter?

Collision resistance is the guarantee that nobody can find two different inputs with the same digest while choosing both inputs freely. MD5 lost it in 2004 and a collision now takes about a second on a laptop. It matters because a digest is only proof of identity if one digest means one file — once somebody can make two files match, a matching MD5 tells you that you hold one of the files they prepared, not which one.

Can an attacker change a file I downloaded and keep the same MD5?

Not if an honest publisher made the original. Altering an existing file while preserving its digest requires a second preimage, and MD5 still resists that — the best published attack is barely better than guessing, and guessing means roughly 2 to the power of 128 attempts. The attack MD5 is vulnerable to requires making both files, so it reaches you when the publisher itself is hostile or compromised, not when someone tampers with a file in transit.

Is MD5 safe for storing passwords?

No, and the reason has nothing to do with collisions. MD5 is fast, so a GPU can test billions of candidate passwords a second, and unsalted MD5s can be looked up in precomputed tables. Replacing it with SHA-256 does not fix this because SHA-256 is fast too. Password storage needs bcrypt, scrypt or Argon2, which are slow deliberately.

Does MD5 still meet FIPS or PCI requirements?

No. MD5 was never one of NIST's approved hash functions, so any framework that defers to that list — including FIPS-validated environments and most interpretations of PCI DSS's requirement for strong cryptography — will reject it for security purposes. Non-security uses such as cache keys are defensible in principle but still get flagged by automated scanning, which is usually easier to resolve by switching than by arguing.

Should I replace MD5 with SHA-1?

No. SHA-1's collision resistance is broken too — publicly, since 2017 — so you would be spending a migration to land in the same position with more characters. Go straight to SHA-256, which has no practical weakness and is the value everybody else publishes. Whether SHA-1 is still safe covers that break in detail.

Is it safe to use MD5 to find duplicate files?

Among files you created or control, yes — nobody has crafted a colliding pair to deceive your deduplication script, and MD5 will group identical files correctly. Among files supplied by people you do not trust, no: a deliberately colliding pair is cheap to make, and a system that treats matching MD5s as proof of sameness can be fed one on purpose.