Hashing: SHA-256, why MD5 is retired, and how passwords should be stored

A hash function turns any input, a word or a whole disk image, into a short fixed-length fingerprint. The same input always produces the same fingerprint, a tiny change produces a completely different one, and there is no key that turns the fingerprint back into the input. Those three properties make hashing one of the most useful tools in security, and also one of the most misused.

What a hash is for

• Integrity: publishing the SHA-256 hash of a download lets anyone check that the file they received is exactly the file that was published.
• Signatures: digital signatures sign a hash of a document rather than the whole document, which is why a weak hash weakens every signature built on it.
• Password storage: a service can store a derived value instead of your password, and compare it when you log in.

Hashing is not encryption. A hash cannot be decrypted, because nothing was locked with a key. If someone tells you a password “is encrypted with MD5”, they are describing a hash, and, as the next sections explain, a weak one.

SHA-256 and the SHA-2 family

SHA-256 belongs to the SHA-2 family defined by NIST in FIPS 180-4. It produces a 256-bit fingerprint and is used everywhere: software updates, TLS certificates, code signing, backups, and many blockchains. SHA-3, standardized later, is built differently and exists as an alternative in case a weakness is ever found in SHA-2. For most purposes today, SHA-256 is the default.

Why MD5 and SHA-1 were retired

A hash must be collision-resistant: it should be infeasible to find two different inputs with the same fingerprint. MD5 lost that property long ago. RFC 6151 records practical collision attacks and advises against using MD5 wherever collision resistance matters, such as digital signatures. SHA-1 followed: researchers demonstrated a real collision in 2017, and NIST announced in December 2022 that SHA-1 should be phased out, with a target date of 31 December 2030. You may still see MD5 used as a quick checksum against accidental corruption, but never trust it against someone deliberately forging a file.

Passwords need more than a hash

Ordinary hashes are designed to be fast, and for passwords that speed is a problem. If a service stores plain SHA-256 hashes and its database leaks, attackers can try billions of guesses per second on graphics cards, and identical passwords produce identical hashes, so one cracked hash reveals every account that used the same password. Two defenses fix this.

1. A salt: a unique random value stored with each password and mixed into the hash. Two users with the same password get different hashes, and precomputed tables of common passwords become useless.
2. A slow, memory-hard password hash: algorithms built to make each guess expensive. The OWASP Password Storage Cheat Sheet recommends Argon2id first (standardized in RFC 9106), then scrypt, then bcrypt, with work factors tuned so a single login stays fast for the service but mass guessing becomes very costly for an attacker.

For you as a user, the lesson is practical. You cannot see how a website stores your password, so assume some day one will be stored badly and leaked. Use a different password for every account, let a password manager generate them, and turn on passkeys or two-factor authentication wherever it is offered. A unique password turns a leak at one site into a leak at one site, not everywhere.

Hashes you can use today

You do not need to be a developer to use a hash. When a project publishes a SHA-256 checksum next to a download, you can compute the file’s hash yourself with shasum -a 256 <file> in Terminal and compare the two values. A match proves the file was not corrupted or swapped in transit, but only if you got the expected value from a source you trust, such as the project’s official site over HTTPS. A plain hash cannot prove who made the file, because anyone can hash anything. For that, systems combine hashes with secrets: an HMAC mixes a hash with a secret key so only key holders can produce a valid tag, and a digital signature hashes the data and signs the result with a private key that only the author holds.