A cryptographic hash is a one-way function that turns any input into a fixed-size fingerprint. That sounds simple, but the choice of algorithm and the way you apply it determines whether your user database survives a breach. SHA-256 is the right tool for one job and the wrong tool for the other, and the difference costs nothing to understand but everything to get wrong.
What a cryptographic hash actually guarantees
A secure hash function maps arbitrary input to a fixed-length digest while satisfying three properties:
- Preimage resistance — given a digest
h, it is infeasible to find any messagemsuch thatH(m) = h. - Second-preimage resistance — given a message
m1, it is infeasible to find a differentm2with the same digest. - Collision resistance — it is infeasible to find any two distinct messages
m1 ≠ m2that hash to the same value.
When all three hold, the digest is a trustworthy fingerprint: change one bit of the input and the output changes completely (the avalanche effect). You can experiment with this behaviour directly in the hash generator — paste a string, flip a single character, and watch every hex digit of the SHA-256 output turn over.
SHA-256 specifics
SHA-256 is defined in FIPS PUB 180-4, the Secure Hash Standard published by NIST. It belongs to the SHA-2 family and produces a 256-bit (32-byte) digest, conventionally rendered as 64 hexadecimal characters. It processes input in 512-bit blocks using 32-bit words and 64 rounds of compression. It is fast, it is well-analysed, and as of 2026 no practical preimage or second-preimage attack exists against it.
That speed is precisely the problem when you misuse it.
Why raw SHA-256 is catastrophic for passwords
A hash function designed for verification is designed to be fast. On a commodity GPU, an attacker can compute on the order of 10 billion SHA-256 hashes per second — and a rig of several GPUs reaches hundreds of billions. When an attacker steals a database table full of SHA256(password) rows, they can run a dictionary of the top million passwords against every single account in seconds. Eight-character passwords fall in minutes; random nine-character passwords in hours.
The math is brutal because the function was designed to be quick. Password storage needs the opposite property: an intentional, tunable slowness that makes mass guessing economically infeasible.
What a password key derivation function does
A password hashing function — also called a key derivation function (KDF) — is built specifically to be slow and expensive. Three are worth knowing:
- bcrypt — introduced in 1999, uses an adaptive cost factor (the “rounds” log₂ value). A cost of 12 means 2¹² = 4096 iterations; each increment doubles the work. bcrypt also has a small 72-byte password truncation limit to be aware of.
- scrypt — adds memory hardness, requiring a configurable amount of RAM (typically tens of megabytes). This blunts GPU and ASIC attacks, which are fast precisely because they have abundant compute cores but limited per-core memory.
- Argon2id — the winner of the 2015 Password Hashing Competition, specified in RFC 9106. It combines the resistance of Argon2i (side-channel attacks) and Argon2d (GPU cracking) and exposes three tunable parameters: memory cost, time cost, and parallelism. It is the recommended default for new systems in 2026.
Every one of these requires a salt: a unique, random value generated per password and stored alongside the hash. The salt defeats precomputed rainbow tables and ensures that two users with the same password get different stored hashes. A salt is not secret — it just has to be unique and unpredictable.
The combination matters: slow function + per-user salt + work factor you can raise over time. You can generate strong, unique passwords to feed into such a system with the password generator.
The MD5 and SHA-1 breakage — integrity, not passwords
A separate failure mode is collision resistance breaking down. MD5 was broken in 2004 when Xiaoyun Wang and colleagues reduced collision complexity from a theoretical 2⁶⁴ to roughly 2³⁹ operations — practical collisions in under an hour on contemporary hardware.
SHA-1 held out longer, but in February 2017 the SHAttered attack by researchers at Google and CWI Amsterdam produced the first public SHA-1 collision: two distinct PDF files with the identical SHA-1 digest 38762cf7f55934b34d179ae6a4c80cadccbb7f0a. The attack ran roughly 100,000 times faster than brute force. SHA-1 was immediately abandoned for TLS certificates and code signing.
NIST responded by formalising a retirement timeline. SP 800-131A already disallowed SHA-1 for new digital signature generation; subsequent revisions extended that: SHA-1 is deprecated through December 31, 2030, and disallowed for all applications after that date. The migration target is SHA-2 (SHA-256, SHA-384, SHA-512) and SHA-3.
Integrity use: good. Password use: bad.
This is the distinction every developer needs to internalise:
| Use case | Right tool | Why |
|---|---|---|
| File integrity, checksums, content addressing (git) | SHA-256 / SHA-3 | You want speed; inputs are large and high-entropy |
| Digital signatures, certificates | SHA-256 / SHA-384 | Collision resistance matters; SHA-1 is being retired |
| Password storage | bcrypt, scrypt, or Argon2id | You need slowness and memory hardness, plus a salt |
| HMAC / message authentication | HMAC-SHA-256 | Keyed hashing; the key provides the secret |
A raw SHA256(password) column is a liability. A raw MD5(password) column is worse — it is not just slow-cracked, it is broken. If you inherit either, treat every stored password as already compromised and migrate to Argon2id at the next login, rehashing transparently.
A practical checklist
- Never hash passwords with MD5, SHA-1, or raw SHA-256.
- Use Argon2id where available; fall back to bcrypt (cost ≥ 12) or PBKDF2-HMAC-SHA-256 (≥ 600,000 iterations) only when you must.
- Generate a unique 16-byte salt per password. Store it next to the hash — it is not secret.
- Parametrise the work factor and revisit it annually as hardware improves.
- Use SHA-256 freely for checksums, HMACs, and integrity verification — that is what it was built for.
Understanding where each algorithm belongs is the difference between a hash that protects your users and one that hands their credentials to an attacker on a commodity GPU. Choose the right tool for the right job, and the cryptography will do the rest.