MD5 vs SHA-1 vs SHA-256

Three hash functions in one sentence each

A cryptographic hash function turns any input into a fixed-size output, called a digest or hash. The same input always gives the same digest, and a tiny change gives a completely different one. If you need the difference between hashing and encryption first, read Hashing vs Encryption.

MD5 produces a 128-bit digest. Ronald Rivest published it as RFC 1321 in April 1992 ^[1].

SHA-1 produces a 160-bit digest. NIST says it has been in use since 1995 ^[2]. It is specified, together with the SHA-2 functions, in FIPS 180-4 ^[3].

SHA-256 produces a 256-bit digest. It is part of the SHA-2 family, specified in FIPS 180-4, the Secure Hash Standard (current version August 2015) ^[3].

Comparison table

Output size: what the numbers mean

The output size is the length of the digest. Here is the word hello hashed with each algorithm, written in hexadecimal (two characters per byte):

MD5     5d41402abc4b2a76b9719d911017c592
SHA-1   aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
SHA-256 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Change one letter to Hello and the SHA-256 digest becomes 185f8db3…6381969, with no visible link to the first. This is what makes digests useful as fingerprints.

A longer digest means more possible outputs. More outputs make it harder to find two inputs with the same digest by brute effort alone. But size is not everything: MD5 and SHA-1 fell because of weaknesses in their internal design, not only because their outputs were short.

What a collision is

A collision is two different inputs that produce the same digest. Every hash function has collisions in theory, because there are infinitely many inputs and only a fixed number of outputs. The goal is that nobody can find one in practice. FIPS 180-4 describes this as it being "computationally infeasible" to find two different messages with the same digest ^[3].

A simple example shows why this matters. Imagine you sign a document by signing its SHA-1 digest, which is how digital signatures usually work. If an attacker can prepare two documents — a harmless contract and a harmful one — with the same digest, you sign the harmless one and the attacker reuses your signature on the harmful one. The signature is still valid, because the digest is the same.

This is not a theory. In 2017 researchers from CWI Amsterdam and Google published SHAttered: two different PDF files with the same SHA-1 digest ^[5].

Collision resistance is different from preimage resistance, which is the difficulty of finding any input for a given digest. Collision attacks on MD5 and SHA-1 do not mean an attacker can reverse a digest back to its input. That distinction matters for the password section below.

MD5: broken where collisions matter

RFC 1321 presented MD5 for digital signature applications, where a large file is "compressed" to a short digest before signing ^[1].

Collision attacks changed that. RFC 6151, published in March 2011, summarises the history: collision pairs were shown in 2004, attack techniques were published in 2005, later improvements found collisions in about a minute on ordinary hardware, and by 2007 collisions had been applied to X.509 certificates ^[4]. Its conclusion is direct: MD5 "is no longer acceptable where collision resistance is required such as digital signatures" ^[4].

RFC 6151 treats HMAC-MD5 separately. HMAC is a keyed construction used to check that a message came from someone who holds a secret key. The RFC says removing HMAC-MD5 from existing protocols may not be urgent, but new protocol designs should not use it ^[4].

MD5 is still common as a quick way to detect accidental corruption, for example a file damaged during a copy. That use does not depend on collision resistance, because random errors do not try to produce collisions. It is a poor choice whenever an attacker could shape the input.

SHA-1: retired by NIST

SHA-1 was designed to be stronger than MD5 and was widely used for signatures and certificates. Earlier, NIST had told federal agencies to stop using SHA-1 where collision attacks are a critical threat, such as creating digital signatures ^[2].

SHAttered, announced on 23 February 2017, was the first practical collision. It took about nine quintillion SHA-1 computations, which the researchers describe as about 6,500 CPU-years and 110 GPU-years ^[5]. That is expensive, but within reach of a well-funded team, and costs of such attacks tend to fall over time.

On 15 December 2022 NIST announced that SHA-1 should be phased out by 31 December 2030, and that users should migrate to SHA-2 or SHA-3 as soon as possible ^[2]. If you find SHA-1 in a system today, treat it as something to replace on a planned schedule.

SHA-256: current standard, carefully stated

SHA-256 is part of SHA-2, which NIST names as a replacement for SHA-1 ^[2]. No practical collision for SHA-256 has been publicly reported as of this writing. That is a statement about current public research, not a promise. Nobody can prove a hash function will never be broken, so "unbreakable" is the wrong word.

SHA-256 is a good default for file checksums, for the hash inside digital signatures, and for HMAC-SHA-256. SHA-3, specified in FIPS 202 (August 2015), is the other family NIST names ^[2][8]; it is not covered in detail here.

Checksums: integrity vs authenticity

Many download pages publish a checksum, for example a SHA-256 digest of an installer. After downloading, you compute the digest of your file and compare it. If they match, the file was not changed or damaged between the checksum and your disk. That is integrity.

It does not prove authenticity, meaning that the file came from the real publisher. If an attacker controls the server, they can replace both the installer and the checksum on the same page. Your comparison will match, and it will prove nothing.

A checksum helps against attackers only when it comes from a channel the attacker does not control. The usual solution is a digital signature: the publisher signs the file or the checksum list with a private key, and you verify it with a public key you obtained earlier and trust. NIST's Digital Signature Standard, FIPS 186-5, says signatures are used to detect unauthorized changes and to authenticate the identity of the signer ^[7]. The hash still matters inside the signature, which is one more reason to avoid MD5 and SHA-1 there.

Why none of them should store passwords on their own

A website should not store your password. It should store a value that lets it check your password. The obvious idea is SHA-256(password), but OWASP rejects it: "Fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly" ^[6].

The problem is speed, not collisions. If a database of hashes leaks, the attacker hashes candidate passwords such as summer2024 and compares the results. A fast hash lets them test a huge number of guesses per second on graphics cards. As a worked estimate with this site's assumptions, a rig doing 10^11 guesses per second would try every 8-character lowercase password (26^8, about 2 × 10^11 options) in about two seconds. MD5 and SHA-1 are also fast, so their collision weaknesses are almost beside the point here.

OWASP recommends functions designed to be slow and, in some cases, memory-hard: Argon2id first, then scrypt, bcrypt for legacy systems, and PBKDF2 when FIPS-140 compliance is required ^[6]. These functions also use a unique random salt per password, which stops attackers from using precomputed tables ^[6]. The full design, with parameters, is in How Passwords Should Be Stored, and salts are explained in What Is a Cryptographic Salt?.

If you maintain an old system that stores MD5 or SHA-1 password hashes, OWASP describes upgrading users to a modern algorithm, for example at their next login ^[6].

Which one should you use?

For new security work, use SHA-256 or another SHA-2 or SHA-3 function ^[2]. Use MD5 or SHA-1 only to read or check old data while you migrate, or for non-security checks where an attacker plays no part. For passwords, use none of the three directly; use a password hashing function such as Argon2id ^[6].

The same advice as a quick lookup: