MD5 Was Broken in 2004. Why Is It Still in Use?

Hash functions sit underneath digital signatures, certificates, version-control systems, and downloaded-file verification, yet most people only notice them when a practical attack makes the news. The history of MD5 and SHA-1 is therefore not just a story about better cryptanalysis; it also shows how slowly an industry can retire an algorithm after its limitations become common knowledge.

What it means for a hash function to break

Saying that "MD5 is broken" can sound as though anyone can now take an arbitrary MD5 digest and instantly recover the original file or password. That is not what happened. Cryptographic hash functions are expected to satisfy several independent properties, and an attack against one of them does not automatically solve the others.

Collision resistance means that an attacker should not be able to construct two different messages with the same digest. This is the property that MD5 and SHA-1 lost. Preimage resistance asks a different question: given one digest, can an attacker find a message that produces it? Password cracking is different again because it usually targets a database of fast, poorly protected password hashes rather than the abstract preimage problem. Collision attacks do not reveal a password automatically, but the speed of MD5 and SHA-1 still makes both unsuitable for password storage.

Those distinctions matter in practice. A file checksum, a digital signature, and a password database all use hashes for different purposes, so the single word "broken" does not describe the risk in each setting.

MD5: from a cautious MD4 successor to a rogue certificate authority

Ronald Rivest designed MD5 in 1991 as a more conservative successor to MD4. Published in April 1992, RFC 1321 explicitly noted that MD4 was being adopted faster than it could be thoroughly reviewed, so MD5 gave up some speed in exchange for a larger safety margin. At the time, its compact 128-bit fingerprint looked like a reasonable engineering choice, and the algorithm spread through applications, protocols, and public-key infrastructure.

Warnings appeared well before the final practical exploit, but 2004 was the turning point. Xiaoyun Wang, Dengguo Feng, Xuejia Lai, and Hongbo Yu published the first pairs of messages with identical MD5 digests, followed by a detailed attack in 2005. Researchers then moved beyond making collision searches faster and started learning how to place useful structure around the calculated collision blocks. RFC 6151 summarizes that progression and ultimately declares MD5 unacceptable wherever collision resistance is required.

Chosen-prefix collisions proved particularly important. Starting from two deliberately prepared documents, an attacker could calculate different appendages that made the final MD5 digests equal. In 2008, Marc Stevens and his collaborators used that technique against a commercial certificate authority and created a rogue intermediate CA certificate. Browsers trusted the original root, so they would also trust certificates issued through the forged intermediate. The demonstration turned an abstract weakness into a direct attack on the web's trust model.

Why MD5 has not disappeared

A vulnerable algorithm rarely vanishes at once. A digest may already be stored in billions of objects, embedded in a file format, or fixed by an interoperability protocol. Replacing it can require every participant to upgrade, old values to be recomputed, and archival data to remain readable. That is why MD5 still appears in long-lived software, package repositories, integrations, and databases created many years ago.

There is also a narrower use case: detecting accidental corruption in an environment where an adversary cannot choose the input. Cryptographic collision resistance is unnecessary for that specific job, so some systems retain MD5 as a familiar and universally available checksum. The boundary is crucial, however. Once an untrusted party can prepare a file deliberately, MD5 is inappropriate for signatures, authenticity checks, content-addressed storage, or any decision where an equal digest is treated as proof of equal content.

Password storage fails for a different reason. Even without considering collisions, MD5 and SHA-1 are far too fast, allowing an attacker to test enormous numbers of guesses per second. Passwords need a deliberately expensive password-hashing or key-derivation function such as Argon2id, scrypt, bcrypt, or PBKDF2, together with a unique salt and appropriate cost parameters.

SHA-1: the warning came before the public collision

NIST standardized SHA-1 in 1995 as a corrected successor to SHA-0. New cryptanalytic results in 2005 substantially reduced the expected work needed to find a collision, and by 2006 NIST was already encouraging a rapid transition to SHA-2 for digital signatures. No complete public SHA-1 collision existed yet, but the original security margin was clearly gone.

The practical endpoint arrived in 2017 when Google and CWI Amsterdam announced SHAttered, the first public collision for the full SHA-1 function. The researchers created two different PDF files with the same digest after roughly nine quintillion SHA-1 computations. The project used work equivalent to about 6,500 CPU-years for its first phase and 110 GPU-years for its second. That was still expensive, but it was within reach of a well-funded organization and removed any remaining case for treating SHA-1 as a sound basis for digital signatures.

Migration still took years because standards, certificates, devices, and archival formats move at different speeds. The twelve-year gap between the first major cryptanalytic warning and SHAttered illustrates that delay, while NIST's continuing SHA-1 transition policy shows that retirement work continues even after a public collision.

SHA-2 and SHA-3 are not two stages of one mandatory upgrade

The SHA-2 family entered the NIST standard in 2002 and includes SHA-224, SHA-256, SHA-384, and SHA-512. SHA-256 remains the most common general-purpose choice for new systems: there are no known practical attacks against the full function, implementation support is broad, and it is suitable for digital signatures, file fingerprints, and other applications that require a modern cryptographic hash.

After the attacks on MD5 and SHA-1, NIST ran an open competition for an algorithm whose design did not repeat SHA-2. Keccak, designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, won in 2012 and became SHA-3 in FIPS 202 in 2015. NIST nevertheless states explicitly that SHA-2 remains secure and viable. The higher number does not make SHA-3 a required replacement for SHA-256; it gives the industry an alternative based on different internal mathematics.

The design difference also affects how the functions may be used. A homemade SHA256(secret || message) construction is vulnerable to a length-extension attack because SHA-256 lets an attacker continue hashing from the published state. SHA-3's sponge construction does not have that specific weakness, but message authentication should still use a standard keyed construction rather than a custom concatenation of secret and data.

HMAC: why a hash sometimes needs a key

Anyone can compute an ordinary hash, so matching it against a trusted value can confirm data integrity but says nothing about who produced it. HMAC adds a shared secret and produces a message authentication code that another holder of the same secret can verify. Mihir Bellare, Ran Canetti, and Hugo Krawczyk standardized the construction in RFC 2104 in 1997.

HMAC performs two nested hash operations instead of using a simple hash(key + message) formula:

HMAC(K, m) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || m ) )

Here K' is the key normalized to the hash function's block size, ipad and opad are fixed padding values, and || means concatenation. The inner operation binds the message to the key; the outer layer hides the intermediate state and prevents the ordinary length-extension technique from continuing it. New systems typically use HMAC-SHA-256 or HMAC-SHA-512.

What to choose today

What our hash generator does

The Hash Generator computes digests in your browser without sending the entered text or selected file to a server. MD5 and SHA-1 remain available for old data and interoperability, while new work can use modern options:

• SHA-256, SHA-384, and SHA-512 from the SHA-2 family;
• SHA3-256 and SHA3-512 using Keccak's sponge construction;
• HMAC for authenticating a message with a secret key;
• CRC32 for non-cryptographic accidental-error detection;
• local file hashing and comparison with a known digest;
• MD5 and SHA-1 for legacy cases in which an existing format requires them.

For a quick comparison, enter "Hello, world," compare MD5's 32 hexadecimal characters with SHA-256's 64, then enable HMAC and add a key. The final value can no longer be reproduced from the message alone because calculating it now requires the same secret.

Related tools

Hash GeneratorCompute MD5, SHA-1, SHA-256/384/512, SHA-3 and CRC32 digests from text or files, live as you type, with HMAC keyed hashing and hash comparison.JWT InspectorDecode a JWT into readable header and payload, inspect expiry and issued-at times, and verify HS256, RS256 or ES256 signatures locally.UUID GeneratorGenerate UUID v4, v7 and v1, plus ULID, NanoID and CUID2-compatible identifiers with cryptographically secure randomness and batch output.Encryption ToolboxIdentify an unknown cipher from its charset, index of coincidence, frequencies and Kasiski repeats; encode one message with every reversible cipher at once with round-trip checks; encrypt with AES-256-GCM; and solve Caesar, Vigenère, Playfair, ADFGX, Bifid or rail fence in the workbench — all in the browser.Webhook Signature VerifierVerify webhook signatures for seven providers, inspect the exact signed payload, check the replay window, and export verification code for Node, Python, PHP and Go.Telegram Webhook TesterDecode Telegram Bot API webhook updates, replay them to any endpoint, and verify or sign Mini App initData with HMAC-SHA256 — entirely in the browser.