MD5 vs SHA-256: Which Hash Should You Use?

MD5 is still one of the most common hashes on the internet, and that is mostly a problem. Collision attacks made it unsafe two decades ago, SHA-1 followed in 2017, and anything that must resist a deliberate attacker belongs on SHA-256 or better. This article covers what broke, what to use today, why passwords need a different algorithm family, and a decision table for common cases. Need a digest right now? Use the hash generator.

What changed: MD5 and SHA-1 are broken

A cryptographic hash is broken when collisions become practical — when an attacker can produce two different inputs with the same digest. MD5 reached that point in 2004, when Xiaoyun Wang's team published an attack computing collisions in hours on ordinary hardware. Chosen-prefix collisions followed, and the Flame malware in 2012 abused a forged MD5 code-signing certificate. A hash whose collisions are forgeable cannot prove a file is untampered.

SHA-1 lasted longer, but not indefinitely. In 2017 Google and CWI announced SHAttered, the first practical collision: two different PDFs with identical SHA-1 digests. A chosen-prefix attack in 2020 made targeted forgeries realistic, and browsers dropped SHA-1 certificates that year. The conclusion is not that MD5 and SHA-1 are useless — they are safe only where nobody is attacking. Checksums, cache keys, and deduplication are fine; signatures, certificates, password storage, and anything an adversary can touch are not.

SHA-256 and SHA-3 today

SHA-256, from the SHA-2 family, is the workhorse. It produces a 256-bit digest, no practical collision or preimage attack is known, and it is the default in TLS, code signing, software distribution, and container image digests. If you need one answer for "which hash", this is it.

SHA-3 is not a replacement but an alternative. Standardised in 2015 and built on the Keccak sponge construction, it exists so that a structural break in the Merkle–Damgård design behind SHA-1 and SHA-2 would not take down every hash at once. Neither solves authentication on its own: to prove a message came from someone who knows a secret, use HMAC-SHA-256 rather than hashing key and message together — plain concatenation is vulnerable to length extension. Compute a keyed digest with the HMAC generator.

Password hashing is a different problem

For passwords, speed is the enemy. SHA-256 runs in nanoseconds, so one GPU can test billions of candidates per second against a stolen database. Password hashing must be deliberately slow and salted: bcrypt (1999, adjustable cost), scrypt (memory-hard), and Argon2 (2015 Password Hashing Competition winner, with Argon2id the current recommendation).

Two details matter as much as the algorithm. The salt is a random per-user value stored with the hash; it defeats rainbow tables and makes identical passwords produce different digests. The work factor — bcrypt's cost, Argon2's iterations and memory — should make one hash take tens of milliseconds on your hardware: fast enough for a login form, slow enough to make offline cracking expensive. Never design your own; use a maintained library.

A quick decision table

The rule of thumb behind every row: if an adversary can touch the data, use SHA-256 at minimum; if the input is a password, use Argon2id or bcrypt; and if you need unpredictability, take it from a cryptographic random source rather than a hash. Everything else is a checksum, and a checksum only has to survive accidents.