If you've ever downloaded a program and seen a string like e3b0c44298fc1c149afbf4c8996fb924… next to the link, that was a hash. Hashes are everywhere: in Git, in API signatures, in cache keys, in passwords… But they aren't all fit for the same job, and picking the wrong one can open a security hole.
What a hash function is
A hash function takes text or a file of any size and returns a fixed-size fingerprint. It has three key properties:
- Deterministic: the same input always produces the same hash.
- Avalanche effect: changing a single character changes the hash completely.
- One-way: you can't rebuild the input from the hash.
For example, the SHA-256 of hello and of Hello look nothing alike, even though only one capital letter changed. Try it in the hash generator: it computes MD5, SHA-1 and SHA-256 at once, in your browser.
The three functions side by side
| MD5 | SHA-1 | SHA-256 | |
|---|---|---|---|
| Size | 128 bits (32 hex chars) | 160 bits (40 hex) | 256 bits (64 hex) |
| Year | 1992 | 1995 | 2001 |
| Practical collisions | Yes, since 2004 | Yes, since 2017 | None known |
| Secure today? | No | No | Yes |
A collision means finding two different inputs with the same hash. With MD5 they can be generated in seconds on an ordinary computer; for SHA-1, Google and CWI published the first practical collision in 2017 (the "SHAttered" attack): two different PDFs with the same hash. None is known for SHA-256.
What each one is good for today
MD5: only against accidents, never against attackers
MD5 is still useful to check that a file hasn't been corrupted by accident (an incomplete download, a failing disk), or to build cache keys and deduplicate data. It's fast and available everywhere. What you must not do is rely on MD5 when someone could tamper with the file on purpose: an attacker can craft another file with the same hash.
SHA-1: on its way out
Git used SHA-1 for years to identify commits and is migrating to SHA-256. TLS certificates signed with SHA-1 stopped being accepted long ago. If you find it in a legacy system, plan the migration; don't pick it for anything new.
SHA-256: the default choice
It's today's standard to verify downloads, sign data, fingerprint certificates or identify content uniquely. If you need "a hash" and don't know which one, choose SHA-256.
The worst mistake: hashing passwords with them
Neither MD5, nor SHA-1, nor even SHA-256 are suitable for storing passwords. The problem isn't that they can be "decrypted", it's that they're too fast: a modern graphics card computes billions of hashes per second, so trying every common password against a stolen database takes minutes. On top of that, without a "salt", two users with the same password get the same hash, and there are precomputed tables (rainbow tables) with millions of hashes of common passwords.
Passwords call for functions that are deliberately slow and salted:
- Argon2id (OWASP's current recommendation)
- bcrypt
- scrypt
- PBKDF2 with many iterations, if you need FIPS compliance
And of course the best defense starts with the password itself: a long, random one, like those made by the password generator, holds up even if the hash leaks.
Hashing isn't encryption (or Base64)
Three concepts that often get mixed up:
- Hashing: one-way. There's no way back.
- Encryption: two-way with a key. Whoever has the key gets the original back.
- Encoding (Base64): two-way without a key. Anyone can decode it; only the format changes. You can see it with the Base64 encoder.
If you want to check that a message really comes from who it claims (a webhook, for instance), a plain hash isn't enough: you need an HMAC, which combines the hash with a secret key. The HMAC generator computes HMAC-SHA256 signatures to verify those integrations.
Quick summary
- Checking a download isn't corrupted? SHA-256 (or MD5 if that's all the vendor publishes).
- Internal cache key or deduplication? MD5 or SHA-256, either works.
- Signing or verifying messages between systems? HMAC-SHA256.
- Storing passwords? Argon2id or bcrypt. Never plain MD5, SHA-1 or SHA-256.