MD5, SHA-1, SHA-256: Which Hash, and For What

Three properties, not one

Almost every argument about hash functions goes wrong in the first sentence, because the word "secure" is standing in for three different guarantees. Preimage resistance says that given only a digest, you cannot work backwards to any input that produces it. Second-preimage resistance says that given a specific input — this contract, this binary — you cannot find a different input with the same digest. Collision resistance says something stronger and stranger: you cannot find any pair of colliding inputs at all, even if you get to choose both of them and neither has to mean anything.

The three are ordered by difficulty for the attacker, and the birthday bound explains why. Finding a preimage for an n-bit digest costs about 2^n work; finding a collision costs only about 2^(n/2), because you are not aiming at a target, you are waiting for any two of your candidates to match. For SHA-256 that is 2^256 against 2^128 — both far out of reach. For MD5 it is 2^128 against a generic 2^64, and cryptanalysis pushed the real figure far below even that. So collision resistance is always the first thing to fall, and it falls a very long time before preimage resistance does.

What "broken" actually happened to

MD5 fell first. Xiaoyun Wang and co-authors published practical collisions in 2004, and within a few years the technique had been refined into chosen-prefix collisions, where the attacker controls the beginning of both colliding messages and can therefore make each one a meaningful document. That is what makes a signature forgery possible: you get a trusted party to sign the harmless half of a colliding pair, then attach their signature to the other half. Today a plain MD5 collision takes seconds on ordinary hardware.

SHA-1 held out until February 2017, when CWI Amsterdam and Google Research published SHAttered: two PDF files, visibly different, with an identical SHA-1 digest. Their announcement puts the cost at 9,223,372,036,854,775,808 SHA-1 computations. That number is not arbitrary — it is exactly 2^63, comfortably below the 2^80 a generic birthday attack on a 160-bit digest would need. Three years later, Leurent and Peyrin extended the result to chosen-prefix collisions, at which point SHA-1 was finished for every adversarial use, and the certificate authorities and version-control systems that still emitted it began the long migration.

Notice what neither result gives an attacker. Nobody can take an MD5 digest you publish and recover the input. Nobody can take an existing file and manufacture a second file matching its MD5. Both attacks require the adversary to construct both halves from the start. That is the exact line between a checksum that catches a corrupted download — the corruption did not get to choose anything — and a signature that has to survive someone who is deliberately building both documents.

The digests, side by side

Run the string "hello" through each algorithm and the differences are immediate. MD5 gives 5d41402abc4b2a76b9719d911017c592, thirty-two hex characters for 128 bits. SHA-1 gives aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d, forty characters for 160 bits. SHA-256 gives 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, sixty-four characters for 256 bits. Every hex character carries four bits, so the digest length in characters is always the bit length divided by four — a fast way to identify an unlabelled hash in a log file or a database column.

Now add a single full stop. sha256("hello.") is 1589999b0ca6ef8814283026a9f166d51c70a910671c3d44049755f07f2eb910 — not one character in common with the digest of "hello" in any predictable position. That is the avalanche property, and it holds just as strongly in MD5, whose digest for "hello." is d94c10e437d18531e122ed0b45badd2a. Avalanche is not the property that failed. MD5 still scrambles beautifully; it is simply that a smart enough attacker can steer two scrambles into the same place.

A forgery you can reproduce: length extension

MD5, SHA-1, SHA-256 and SHA-512 all share the Merkle-Damgard construction: the message is padded, split into fixed blocks, and each block updates a running internal state. The digest you publish is that internal state. Which means anyone who has your digest can load it back into the algorithm and keep hashing, as if they had been there all along. This is the length-extension property, and it is not a bug in any of these functions — it is what the construction does.

Here it is carried out. Take a naive authentication tag built as sha256(secret + message), with a 32-byte secret and the message user=alice&role=viewer. The legitimate tag begins 0556f5e825e91626. An attacker who knows only the message, the tag and the length of the secret — not the secret itself — can resume SHA-256 from that tag, append the ten padding bytes 800000000000000001b0 that the original hashing would have inserted, then append &role=admin. The tag that comes out is cca75089ae751c4359a577329d74d9ba345ed7e5f83f988583b2baa16cad5efe, and it is byte-for-byte the digest the server computes over the extended message. The forgery verifies. The secret was never known.

The fix is not a longer digest and not a different SHA-2 variant. It is HMAC, which nests the hash twice with two derived keys so the published tag is no longer a resumable internal state. HMAC-SHA-256 over the same key and message gives 2ad69479d608c0fc4c89387db138aebb0bbee3b35d46057726228cacfc8a1478, and no amount of appending gets you a valid extension of it. SHA-3 is immune for a different reason: its sponge construction only outputs part of the internal state, so the digest does not tell you where the algorithm was.

None of these is a password hash

This is the mistake that costs the most, and it has nothing to do with collisions. General-purpose hashes are engineered for throughput, and they deliver it. Measured on a single core over a 64 MB buffer, MD5 runs at 632 MB/s, SHA-256 at 1,075 MB/s and SHA-1 at 1,357 MB/s. The ordering is worth a second look: SHA-256 is 70% faster than MD5 here, because modern processors ship dedicated SHA instructions and no MD5 instruction. "MD5 is faster" stopped being reliably true years ago.

Speed is exactly the wrong property for a stored password, because the attacker with your database benefits from it far more than you do. You hash one password per login; they hash billions per second across a rack of GPUs. Password hashing functions invert that trade deliberately. On the same machine, PBKDF2-SHA-256 at 600,000 iterations takes 148 milliseconds per password, and scrypt with N=131,072 takes 397 milliseconds. That is roughly seven passwords per second instead of millions — a deliberate handicap you pay once per login and the attacker pays once per guess.

So the correct answer to "which hash for passwords" is none of the ones in this article. Use Argon2id where you can choose freely, bcrypt where the platform gives you nothing else, scrypt or PBKDF2 where a standard demands them, always with a unique random salt per user. SHA-256 keeps its place inside those constructions — PBKDF2-SHA-256 is built on it — but it is the primitive, not the scheme.

SHA-3 is not a bigger SHA-2

The numbering invites the wrong conclusion. SHA-2 succeeded SHA-1 as an improved design in the same lineage; SHA-3 did not succeed SHA-2 in that sense at all. It came out of an open competition NIST ran from 2007, was won by the Keccak team, and was standardised in FIPS 202 in 2015 — while SHA-2 remained perfectly healthy and remains so today. NIST has never told anyone to migrate off SHA-2.

The point of SHA-3 is architectural diversity. Because it is a sponge rather than a Merkle-Damgard chain, an attack that broke SHA-2 would very probably not touch it, and the world would have a drop-in replacement ready. The sponge also removes length extension for free, which is why some designs prefer it even now. Its cost is speed: SHA3-256 measured 317 MB/s on the same hardware where SHA-256 hit 1,075 MB/s, largely because the hardware accelerates one and not the other. Choose SHA-3 when you want the different construction, not when you want more bits — SHA3-256 and SHA-256 offer the same 256.

A short decision list

Signing anything, verifying a download from a hostile network, building a Merkle tree, deriving a content address: SHA-256. Storing a password or deriving a key from one: Argon2id, bcrypt or scrypt, never a bare hash. Authenticating a message with a shared secret: HMAC-SHA-256, not sha256(secret + message), for the reason demonstrated above. Deduplicating files, keying a cache, sharding a hash table, spotting a truncated transfer: MD5 is still fine and still fast enough, provided nobody in the picture benefits from a collision.

One test settles the doubtful cases. Ask whether anyone who benefits from two inputs sharing a digest also gets to choose those inputs. If the answer is no — a disk fault, a flaky cable, a partial upload — a broken collision resistance costs you nothing. If the answer is yes, or might become yes when the data leaves your own machine, you need a hash whose collision resistance is intact, and that means SHA-256 or better.

Frequently asked questions

Is MD5 safe to use in 2026?

Only where no adversary benefits from a collision. MD5 lost collision resistance in 2004 and a collision now takes seconds, so any use where someone could gain by making two different inputs share a digest — signatures, certificates, integrity checks over an untrusted network, deduplication of attacker-supplied files — is unsafe. Uses where the only threat is accident remain fine: verifying that a copied file did not truncate, keying a cache, sharding data across servers, comparing local backups. MD5 has not lost preimage resistance, so a published md5 digest does not reveal its input either. The pragmatic rule is that MD5 is a fast fingerprint, not a security control. It is also no longer even the fastest option: measured on one core, SHA-256 ran at 1,075 MB/s against MD5's 632 MB/s, because processors carry SHA instructions. If speed was your reason for MD5, that reason has expired.

Can a SHA-256 hash be decrypted or reversed?

No, and the word decrypt does not apply — hashing is not encryption, because there is no key and no intended way back. SHA-256 maps inputs of any length onto 256 bits, so infinitely many inputs share each digest and the original cannot be singled out even in principle. Recovering an input means brute force: guessing candidates and hashing each until one matches. That is why so-called hash-cracking sites work at all. They do not reverse anything; they hold precomputed tables of digests for common inputs and look yours up. Against a random 32-byte value the lookup fails and 2^256 guesses remain. Against the string "password" it succeeds instantly. The practical consequence: a digest of a low-entropy secret is barely a secret, which is precisely the reason password storage adds a per-user salt (defeating shared tables) and a deliberately slow function (defeating fast guessing).

Should I use SHA-512 instead of SHA-256 for more security?

Rarely worth it. SHA-256 offers 128 bits of collision resistance and 256 of preimage resistance; SHA-512 doubles both to 256 and 512. Since no attack against SHA-256 comes anywhere near 2^128, the extra margin buys nothing you can point at, while the digest doubles to 128 hex characters in every database column, URL and log line that has to carry it. There are two real reasons to pick SHA-512. One is performance on 64-bit software without hardware SHA support, where SHA-512's 64-bit words can outrun SHA-256 — though on hardware that accelerates SHA-256 the ordering reverses, as it did here at 1,075 MB/s against 516 MB/s. The other is a specification that requires it. SHA-512/256, a truncated variant defined in FIPS 180-4, gives the 64-bit-word speed with a 256-bit output and is the tidier compromise when you need both.

Why can I not just hash passwords with SHA-256 and a salt?

A salt fixes one problem and leaves the bigger one untouched. It stops precomputed tables and forces the attacker to attack each account separately — genuinely valuable. What it cannot change is the cost per guess. SHA-256 is built to be cheap, and an attacker with your salted database attacks each account at whatever rate their hardware allows, which on a rack of GPUs is enormous. The defence has to make each individual guess expensive, and that is what a password hashing function does. Measured here, PBKDF2-SHA-256 at 600,000 iterations costs 148 ms per password and scrypt at N=131,072 costs 397 ms; Argon2id adds a memory cost on top, so a GPU cannot simply run thousands of instances in parallel. Salt and slowness are both required, and only the second is a property of the algorithm you choose. Use Argon2id, bcrypt or scrypt, and let SHA-256 sit inside them where it belongs.

What is length extension, and does it affect me?

It affects you only if you built an authentication tag as hash(secret + message). Because MD5, SHA-1 and the SHA-2 family publish their internal state as the digest, anyone holding that digest can resume the computation and produce a valid tag for the message with extra data appended, without ever learning the secret. This is not theoretical: starting from a real tag over a 32-byte secret and user=alice&role=viewer, appending the ten padding bytes 800000000000000001b0 and then &role=admin produced cca75089ae751c4359a577329d74d9ba345ed7e5f83f988583b2baa16cad5efe, which is exactly what the server computes. Because query parsers commonly take the last occurrence of a repeated key, that extension flips the role. Two fixes work: use HMAC, which is designed for keyed authentication and is not extendable, or use SHA-3, whose sponge construction never exposes the full state. If you are simply hashing a file with no secret involved, length extension does nothing to you.

Do I need to migrate from SHA-2 to SHA-3?

No. NIST standardised SHA-3 in FIPS 202 as an alternative, not a replacement, and continues to approve the SHA-2 family in FIPS 180-4 with no deprecation in sight. SHA-3 exists because relying on a single construction is a systemic risk: SHA-1 and SHA-2 share a design lineage, so a breakthrough against one raised reasonable worry about the other. Keccak's sponge is a different mechanism entirely, which is the whole point. Reach for SHA-3 in three situations. When a protocol or regulator specifies it. When you want length-extension immunity without wrapping everything in HMAC. When you are designing something intended to outlive the current cryptographic consensus and want construction diversity. Otherwise SHA-256 remains the sensible default, and it is usually faster because processors accelerate it: here 1,075 MB/s against 317 MB/s for SHA3-256. Note also that the security level is identical — SHA3-256 and SHA-256 both give 256-bit digests and 128-bit collision resistance.