MD5 vs SHA-1 vs SHA-256, and Why Not for Passwords

MD5, SHA-1 and SHA-256 all turn any input into a short, fixed-length digest, but they are not interchangeable. MD5 and SHA-1 have known collisions and should not be used for signatures or password storage. Use a dedicated function such as bcrypt, scrypt, or Argon2 to store passwords. For checksums and signatures, SHA-256 is the practical default. To see the digests side by side, paste text or open a file in the Hash Generator.

The algorithms at a glance

Item	MD5	SHA-1	SHA-256	SHA-512
Specification	RFC 1321	FIPS 180-4	FIPS 180-4	FIPS 180-4
Digest size	128 bits	160 bits	256 bits	512 bits
Hex length	32 characters	40 characters	64 characters	128 characters
Collisions	Found, and quick to produce	Found	None published for the full function	None published for the full function
Status	Not for signatures (RFC 6151)	To be phased out by the end of 2030	In the SHA-2 family	In the SHA-2 family

Here is the same six-character input through three of them:

Input: ZEKILO

MD5      f36f86467ce6ba1a1063f6e7019d5e6d
SHA-1    42d40f3480e77ccf59395369cc957ec5a2bf7c4b
SHA-256  f1dfccaf4a395154a1b494c0f0e068765a099f596f3e79934dcc98a2fda67f26

A hash is deterministic: the same bytes always give the same digest. Change anything and the digest changes completely. The lowercase input zekilo has the SHA-256 digest fef1d7d382d3b5d9f0c91e96273a8e4c7f446805b4a08bbb625dc2f742b4177b, which shares nothing recognizable with the one above. A trailing line break counts too, which is the most common reason two people get different hashes for “the same” text.

What a hash promises

RFC 6151 lists the three properties a message digest algorithm is designed to provide:

• Collision resistance: it should be infeasible to find any two different inputs with the same digest.
• Pre-image resistance: given a digest, it should be infeasible to find an input that produces it.
• Second pre-image resistance: given one input, it should be infeasible to find a different input with the same digest.

A hash is also not encryption. There is no key, and the OWASP Password Storage Cheat Sheet describes hashing as a one-way function. A digest can only be compared with the digest of a candidate input.

What went wrong with MD5 and SHA-1

MD5. RFC 6151, published in March 2011, summarizes the research: an attack published in 2006 can find an MD5 collision in about one minute on a standard notebook PC, and collision attacks were successfully applied to X.509 certificates. Its conclusion is that MD5 is no longer acceptable where collision resistance is required, such as digital signatures. The same RFC notes that the best known pre-image attack still has a complexity of 2^123.4, so the break is about collisions, not about turning a digest back into its input.

SHA-1. On December 15, 2022, NIST announced that SHA-1 should be phased out by December 31, 2030, in favor of the SHA-2 and SHA-3 families, and recommended that anyone relying on SHA-1 for security migrate as soon as possible. The announcement explains that collision attacks have been used to undermine SHA-1 in recent years.

Why a collision matters: if someone can prepare two different documents with the same digest, a signature made over one is equally valid for the other. That is why signatures and certificates need a hash without known collisions, and why SHA-256 or another member of SHA-2 or SHA-3 is used there today.

Why none of them should store passwords

This is a separate problem, and it applies to SHA-256 as much as to MD5. General-purpose hashes are designed to be fast. The OWASP cheat sheet states it directly: fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly. If a table of plain SHA-256 digests leaks, every guess an attacker tries costs almost nothing, and identical passwords have identical digests.

Password storage therefore uses functions built for this job:

• They are deliberately slow, with a work factor you can raise as hardware improves, and Argon2id and scrypt also require a configurable amount of memory.
• They mix in a salt, a unique random value per password, so the same password stored twice gives different results and precomputed lookup tables are useless. OWASP notes that most widely used libraries generate and manage the salt for you.

As of October 2026, the OWASP cheat sheet recommends these minimum settings:

Function	Minimum configuration recommended by OWASP
Argon2id	19 MiB of memory, an iteration count of 2, 1 degree of parallelism
scrypt	Cost parameter 2^17, block size 8, parallelization 1
bcrypt	Work factor 10 or more, with a password limit of 72 bytes
PBKDF2-HMAC-SHA-256	600,000 iterations or more, for systems that need FIPS-140 compliance

In practice, call the password hashing API of your language or framework and do not write a loop around SHA-256 yourself. OWASP’s order of preference is Argon2id first, scrypt if Argon2id is not available, and bcrypt for legacy systems.

The user’s side matters as well: a long random password leaves far less room for guessing. The Password Generator creates a 16-character password from 94 possible characters by default, which is about 104.9 bits of entropy. Generated passwords are not recorded. Save them in a password manager right away.

Which one to use

Task	Use
Compare a downloaded file with its published checksum	SHA-256
Digital signatures and certificates	SHA-256 or another SHA-2 or SHA-3 hash
Authenticate a message with a shared secret key	HMAC-SHA-256
Store user passwords	Argon2id, scrypt or bcrypt
Spot accidental changes where nobody is trying to cheat	Any of them, though SHA-256 is simpler

Two reference values you can reproduce: a file that contains only the three bytes abc, with no line break, has the SHA-256 digest ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad. And HMAC-SHA-256 of ZEKILO with the key zekilo-secret is 685de252cb7c60a51aedb9b4c14903d26efb4bb2a11c31531f4388f0badc270f. HMAC combines the message with a key, so only someone who knows the key can produce a matching value. RFC 6151 names HMAC-SHA-256 as an alternative to HMAC-MD5 for new designs.

A checksum only proves that your copy matches the value you compared it with. If the checksum comes from the same place as the file, it detects a damaged download but not a deliberately replaced one.

Checking a hash with ZEKILO Dev

1. Open the Hash Generator and type or paste text, or open a file.
2. MD5, SHA-1, SHA-256, SHA-384 and SHA-512 are shown together. Switch the output between lowercase hex, uppercase hex and Base64, or turn on HMAC and enter a key.
3. To verify a download, paste the expected hash into the Compare tab. Upper and lower case are treated as the same.

Text and files are hashed inside your browser and are not sent to a server.

Summary

• MD5 (128 bits) and SHA-1 (160 bits) have known collisions. Do not use them for signatures or certificates.
• SHA-256 is the practical default for checksums, signatures and HMAC.
• No plain hash, including SHA-256, is suitable for storing passwords, because it is fast to compute. Use Argon2id, scrypt or bcrypt with their built-in salt.
• A hash is a one-way function, not encryption, and a single changed byte, even a line break, produces a different digest.