SHA-256 vs MD5: Which Is Broken, and What For

A hash function takes input of any size and returns a fixed-length fingerprint. The same input always gives the same fingerprint, and changing a single bit changes roughly half the output bits — an effect usually called the avalanche property. What separates a usable hash from a broken one is not speed or output length, but whether anyone has found a way to produce two inputs with the same fingerprint on purpose.

What "broken" actually means

Two different inputs sharing a fingerprint is called a collision. With a large enough output, collisions exist mathematically but cannot be found in any practical amount of time. A hash is broken when someone finds a shortcut — a method that produces collisions to order rather than by brute force.

MD5 fell to exactly that in 2004, and the attack has only got cheaper since; collisions can now be produced on ordinary hardware in seconds. SHA-1 followed in 2017, when a research team demonstrated two different PDF files with identical SHA-1 digests. SHA-256 has no such shortcut and, after two decades of public analysis, no credible sign of one.

Why a collision is worse than it sounds

The danger is not that two random files might clash. It is that an attacker who controls both inputs can prepare a harmless document and a malicious one that hash identically. Anything that trusts the fingerprint as proof of identity — a signature, a certificate, an integrity check, a deduplication key — will treat the two as the same object. That is why a broken hash is unusable for security even though it still computes fine.

The mistake that matters most: passwords

Reaching for SHA-256 to store passwords is the most common misuse of a good hash, and it is a serious one. SHA-256 is designed to be fast, which is exactly what you want for verifying a download and exactly what you do not want for a password. Speed is the attacker asset: modern hardware tries billions of SHA-256 guesses per second against a stolen database.

Password hashing needs an algorithm that is deliberately slow and deliberately memory-hungry, with a per-user salt and a cost factor you can raise as hardware improves. bcrypt, scrypt and Argon2 exist for this and nothing else. A general-purpose hash, however strong, is the wrong tool.

For file integrity you want the fastest secure hash you can get. For passwords you want the slowest one you can afford. Same primitive, opposite requirements.

What each one is fine for

• SHA-256 — signatures, certificates, integrity checks, content addressing, commit identifiers. The sensible default.
• SHA-384 and SHA-512 — the same guarantees with a longer digest; on 64-bit hardware SHA-512 is often faster than SHA-256.
• SHA-1 — legacy compatibility only, and never where an adversary controls the input.
• MD5 — non-adversarial checksums against accidental corruption, cache keys, and nothing else.

Hashing is not encryption

Encryption is reversible with a key; that is its purpose. Hashing is not reversible at all, because output far smaller than input cannot possibly contain it. When a site claims to have recovered a hashed value, it did not decrypt anything — it guessed inputs until one produced a matching fingerprint. That works precisely because unsalted fast hashes of common passwords have already been tabulated, which is the whole argument for salt.

Reading a digest

Digests are shown as hexadecimal, so the character count is twice the byte count: MD5 is 32 characters, SHA-1 is 40, SHA-256 is 64. Length alone tells you which algorithm produced a value, and it tells you nothing about whether that algorithm is still safe. Comparing two digests should be a constant-time comparison in security contexts, since a naive one leaks how many leading characters matched.