MD5 in 2026 — Legacy Checksums Only

A tutorial still shows md5(password) before insert. Comments say “hashing is hashing.” That advice was wrong years ago and is malpractice in 2026. MD5 is a fast cryptographic hash with known collision attacks. Fast is the opposite of what you want for password verification, and collisions mean MD5 is the wrong tool whenever an attacker might craft inputs.

What MD5 is good at (narrowly)

• Fingerprinting files in legacy manifests that already standardized on MD5
• Quick “did this download match the published digest?” checks on trusted mirrors
• Migrating old systems where you must verify historical checksums

Even here, prefer publishing SHA-256 alongside or instead. MD5 collisions are practical in some settings; a determined adversary can sometimes produce two inputs with the same MD5.

What MD5 is not

Use	Verdict
Password storage	Never
API request signatures (security)	Never
TLS / certificate anything	Never
Proof a file was not maliciously altered	Weak / insufficient
Deduping cache keys in a closed system	Sometimes OK (non-security)

If the threat model includes an attacker, MD5 is not your integrity story.

Why password + MD5 fails so hard

1. Speed — GPUs test billions of MD5s per second.
2. No salt in bad tutorials — rainbow tables finish the job.
3. Even salted MD5 — still far too fast; use a slow KDF.
4. Collisions — irrelevant for password guessing, but a reminder the primitive is retired for security design.

Store passwords with Argon2id (preferred where available), bcrypt, or scrypt. Let a vetted library handle salt and parameters. Your app should call verify(password, storedHash), not hand-roll hashing.

Migrating off MD5 password fields

If you inherited MD5 password hashes:

1. On successful login, rehash with Argon2/bcrypt and replace the stored value.
2. Optionally force reset for inactive accounts.
3. Never log raw passwords “to debug MD5 mismatches.”
4. Do not invent a double-hash like md5(sha1(pw)) and call it modern.

Document the migration flag in the user row (hash_version) so verify can try the right algorithm.

Checksums in build pipelines

For artifacts:

# Prefer
sha256sum dist/app.zip

# Legacy verify only when the publisher still prints MD5
md5sum dist/app.zip

Use md5-hash when you need to match an old published digest or explain to a teammate what an MD5 looks like — not when designing auth.

Talking to non-security stakeholders

“MD5 is a checksum people used in the 90s and early 2000s. We still see it on old download pages. We do not use it to protect accounts.” That one paragraph prevents a PM from asking why the “simple hash” is blocked in code review.

Same conversation applies to “can we just MD5 the session token?” Session identifiers need cryptographic randomness and proper cookie flags — not a fast hash of the user id. If a proposal mentions MD5 anywhere near auth, identity, or signatures, send it back for a redesign.

Content-addressed storage caveat

Some internal caches still key blobs by MD5 because a legacy NAS or media tool does. That can be acceptable inside a trust boundary where collision risk is managed operationally. Do not expose those digests as proof to end users that a download is authentic; publish SHA-256 for anything public-facing.

Bottom line

MD5 remains a compatibility tool for legacy non-adversarial checksums. It is not a password feature, not a modern integrity guarantee against attackers, and not something to learn from random auth tutorials. If security matters, pick a modern construction and leave MD5 in the museum drawer labeled “verify old files only.”