Why SHA-256 is more secure than MD5

Hash algorithms are the quiet workhorse behind file integrity, password storage, digital signatures, and blockchains. But not all hash functions are equally secure: MD5, ubiquitous for decades, is now considered broken. This article explains why — and when SHA-256 (or the even stronger SHA-512) is the right choice.

What is a hash function?

A cryptographic hash function maps an input of any length (file, text, data stream) to a fixed-length output — for example 128 bits for MD5 or 256 bits for SHA-256. The result is called a hash or digest. The function is deterministic (the same input always yields the same hash) but practically irreversible.

Three properties are critical here: preimage resistance (from a hash, you should not be able to reconstruct the input), second-preimage resistance (given an input, you should not be able to find a second input with the same hash), and collision resistance (it should be practically impossible to find any pair of inputs with the same hash). Once one of these properties fails, the algorithm is considered compromised for security applications.

A short history: MD5, SHA-1, SHA-2

MD5 was designed by Ron Rivest in 1991, with a 128-bit output. At the time it was an improvement over MD4 and remained the standard for file checksums and password hashes for years. SHA-1, standardized by the NSA in 1995, delivered 160 bits and seemed safe for a long time. Both belong to the same family of Merkle-Damgård constructions with Boolean operations per round.

The SHA-2 family was published by NIST in 2001: SHA-224, SHA-256, SHA-384, and SHA-512. They are structurally related to SHA-1 but use significantly more rounds, larger internal states, and longer outputs. SHA-3 (Keccak, 2015) is based on a completely different sponge construction and is intended as a reserve in case SHA-2 ever becomes structurally vulnerable.

How MD5 and SHA-1 fell

Already in 2004, Wang, Feng, Lai, and Yu demonstrated the first practical collision for MD5. Two different inputs produced the same hash — in minutes on standard hardware. In 2008, a research team led by Sotirov and Stevens showed that this could be used to issue forged SSL certificates. Since then, MD5 has been off-limits for any security application.

SHA-1 followed in 2017 with the famous SHAttered attack by Google and CWI Amsterdam: two PDF files with identical SHA-1 hashes but different content. The attack cost roughly 110 GPU-years — expensive, but affordable for nation-states and large organizations. Browsers, git hosts, and CAs have been actively phasing out SHA-1 since. SHA-256 has so far seen no comparable attack; classical brute-force collisions would be in the 2^128-operation range — astronomical.

What SHA-256 does better

SHA-256 produces a 256-bit output. This puts its theoretical collision resistance, by the birthday paradox, at 2^128 — a number far beyond any conceivable compute power today. In addition, SHA-2 has twice as many rounds as SHA-1 (64 vs. 80, but with more complex mixing) and a larger internal state. Even a drastic reduction in security from future cryptanalysis would still leave plenty of margin.

In practice, SHA-256 is very fast on modern CPUs — Intel and AMD have offered dedicated instruction-set extensions (SHA-NI) for years. ARM has equivalent crypto extensions. For high throughput (e.g. file hashing in backup tools), SHA-256 often isn't the bottleneck anymore. If you need more margin or want to take full advantage of native 64-bit architectures, go for SHA-512.

Which algorithm when?

A pragmatic rule of thumb:

• MD5: only for non-security-critical checksums (e.g. fast deduplication, cache keys, verification against accidental bit errors). Never for signatures, certificates, or password hashes.
• SHA-1: avoid. Tolerated in legacy systems (e.g. Git commit IDs), but in any new application replace it with SHA-256.
• SHA-256: today's de-facto standard. For TLS certificates, JWT signatures (HS256/RS256), digital signatures, file integrity, blockchain (Bitcoin), and anywhere collision resistance matters.
• SHA-512: same security philosophy, double the hash length. Recommended when 256 bits of margin isn't enough, or when 64-bit CPUs compute it faster than SHA-256.

SHAttered: how Google finally killed SHA-1 in 2017

In February 2017, researchers at Google and CWI Amsterdam published the first practical SHA-1 collision: two different PDF files that produced the same SHA-1 hash. The project was called 'SHAttered'. The two PDFs looked different visually (one showed a red rectangle, the other blue), but had byte sequences that the SHA-1 function mapped to the same output. This was no longer a theoretical exercise — it was a practical attack with real consequences.

The computational effort was enormous: around 6,500 CPU years for the first phase and 110 GPU years for the second. In 2017 cloud rental prices that was roughly USD 110,000 — a lot for an afternoon, but affordable for state actors or well-funded criminals. Within days of publication, browser vendors, Git tools and version control systems disabled SHA-1 for security-critical uses.

The lesson: 'no practical collision known' isn't 'safe'. SHA-1 had been considered theoretically broken since 2005, but practical demonstrations were missing. For twelve years most systems stayed on SHA-1 — 'it works, doesn't it'. Then SHAttered landed, and suddenly everybody was scrambling. Anyone still running SHA-1 in production in 2026 (yes, it happens) is following exactly the same pattern. For SHA-2 (i.e. SHA-256 and SHA-512) there isn't even a theoretical attack close to a cryptographically relevant threshold — but that isn't an argument for staying with it forever.

Why SHA-256 is wrong for passwords (even though everyone does it)

One of the most frequent confusions in code reviews: 'we hash passwords with SHA-256, that's safe, right?'. No, it isn't — and not because SHA-256 itself is unsafe, but because it's too fast. A modern GPU computes about 10 billion SHA-256 hashes per second. That means: an 8-character password with letters and digits (about 218 trillion combinations) is fully brute-forced in under six hours — an attack you can rent for a few hundred dollars.

What you actually need are slow, salt-capable algorithms explicitly built for password hashing: Argon2id (2026's recommendation for new systems), bcrypt (still acceptable with cost ≥12), or scrypt. These functions are deliberately compute- and memory-intensive. Argon2id with default parameters takes about 100 ms per hash on a normal server CPU — meaning even with a GPU farm you only achieve about 100 attempts per second instead of 10 billion. That is the factor that turns an 8-character password from '6 hours of brute force' into '6 million years'.

So if you're building a login form: SHA-256 is not the tool. If you have an existing database with SHA-256-hashed passwords: on every successful login, rehash the password with Argon2id and replace the old hash. That's a painless migration over a few months. What doesn't work: 'we just chain 1000 SHA-256 rounds, then it's slow enough'. That's PBKDF2, and in 2026 it is only acceptable as a transition — Argon2id is markedly more resistant against GPU and ASIC attacks.

Code audit: where MD5 and SHA-1 are still hiding

Anyone taking over a codebase today typically finds MD5 or SHA-1 both in places where it doesn't hurt and places where it does. In a 30-minute audit, run through the following search patterns:

• Password fields. grep -rn 'md5(\$password' ., grep -rn 'sha1(\$pwd' .. Every match is a critical vulnerability that needs migration to Argon2id before the next release.
• Signatures and HMAC. Search for hash_hmac('md5', hmac.MD5, HMACSHA1. Here MD5 is almost always wrong — HMAC-MD5 isn't practically attacked yet but it's not a modern standard. Migrate to HMAC-SHA-256.
• File integrity checks. md5sum and sha1sum in build pipelines, backup scripts, deployment tools. If the hashes only catch transmission errors (no malicious attacker involved), MD5 is fine. If an attacker could manipulate the file (software update, licence file), switch to SHA-256 immediately.
• Cookie tokens and session IDs. md5(uniqid()) is a classic anti-pattern that was pervasive in late-2000s PHP codebases. The output isn't random enough. Solution: random_bytes(32) in PHP, crypto.randomBytes(32) in Node.js — no hashing needed.
• Database indices on hash columns. An MD5 column as VARCHAR(32) used as primary key or index — technically works, but rarely optimal. When migrating to SHA-256, widen the column to VARCHAR(64), don't drop old data, keep both hashes in parallel until a full switch is feasible.

If you want to check a concrete hash against an unknown algorithm: our hash generator computes MD5, SHA-1, SHA-256, and SHA-512 side by side for the same input. Two tabs let you compare hex format and length to identify the algorithm (MD5 = 32 hex chars, SHA-1 = 40, SHA-256 = 64, SHA-512 = 128).

What quantum computers will do to SHA-256

A question that comes up in every other crypto talk: 'does quantum break SHA-256?'. Short answer: no, but it halves the effective security. Grover's algorithm on a sufficiently large quantum computer breaks a hash function in 2^(n/2) tries instead of 2^n. For SHA-256 that means: instead of 256 bits of security against pre-image attacks, 128 bits remain. 128 bits of security still count as sufficient for decades to come.

Practically: SHA-512 is especially relaxed against quantum attacks — its bit security also halves, but 256 remaining bits is enormous. Anyone planning absolute long-term security for very long-lived archives (notarial records, medical data with retention periods over 50 years) can switch to SHA-512 without performance issues. For everyday web applications, SHA-256 remains the balanced choice.

Frequently asked questions

Is SHA-256 quantum-safe?

Symmetric primitives like hash functions are much more robust against quantum computers than asymmetric schemes (RSA, ECDSA). Grover's algorithm effectively halves the bit security — SHA-256 would still have about 128 bits of security against an ideal quantum computer, which is practically sufficient. For more margin, use SHA-512 or SHA-3.

Do I need SHA-256 for passwords, or something else?

Neither MD5 nor SHA-256 alone is suitable for password storage. They're too fast — attackers can try billions of hashes per second. For passwords, use intentionally slow algorithms like bcrypt, scrypt, or Argon2, which apply a salt and a configurable work factor.

Is SHA-3 better than SHA-256?

Not necessarily. SHA-3 is structurally different and therefore a useful diversification — if SHA-2 is ever theoretically attacked, SHA-3 remains as a backup. In practice, however, SHA-256 is currently more broadly supported, faster in many hardware implementations, and the right choice for most applications.

Are SHA-256 and SHA-2 the same?

SHA-2 is the family, SHA-256 is one specific algorithm in that family. SHA-2 covers SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256. The numbers indicate output length in bits. SHA-256 is by far the most widespread member, followed by SHA-512 for the most security-critical applications.

What is a salt and why should I use one?

A salt is a random string (typically 16–32 bytes) appended to the password before hashing and stored alongside the hash. Without a salt, every user with the same password produces the same hash — an attacker with a rainbow table (precomputed hash-to-password list) can do instant lookups. With a unique per-user salt, every rainbow table becomes useless. Argon2id and bcrypt generate the salt automatically — manual solutions like 'SHA-256(password + "my_secret_salt")' are anti-pattern.

Is Bitcoin safe if SHA-256 is ever broken?

Bitcoin uses SHA-256 (actually double SHA-256) for mining and block hashes. If SHA-256 ever became collision-vulnerable, Bitcoin miners still couldn't simply 'reverse compute' — the difficulty lies in finding a hash matching a specific pattern (leading zeros), not in inverting. The question is still fair: a theoretically successful attack would likely force a soft fork to SHA-3 or a post-quantum-safe hash. The effort would be significant but operationally feasible within the Bitcoin ecosystem.