Why not just SHA-256?
A regular cryptographic hash like is the right tool for integrity, but the wrong tool for storing passwords, and the reason is the property that makes it good elsewhere: it is fast. An attacker who steals a database of SHA (Secure Hash Algorithm)-256 password hashes can try billions of guesses per second on commodity hardware, because each guess is just one fast hash. Common passwords fall almost instantly. Speed, the virtue of a general-purpose hash, is a liability here.
Password storage needs a hash that is deliberately slow and resistant to specialized hardware. Three building blocks make that work: salting, a tunable work factor, and memory hardness.
Salting: defeating precomputation
A salt is a unique random value stored alongside each password hash and mixed into the hashing. Without salts, identical passwords produce identical hashes, so an attacker can precompute a giant table of common-password hashes once (a "rainbow table") and look up every match instantly. A unique salt per password makes that precomputation worthless: the attacker must attack each hash individually, and the same password hashes differently for every user. Modern password-hashing functions generate and store the salt for you.
Work factor: making each guess expensive
A work factor (or cost parameter) controls how much computation each hash takes. Set it so a single hash is slow enough to be unnoticeable for a legitimate login (a few hundred milliseconds) but punishing at scale. Because it is a parameter, you can raise it over the years as hardware gets faster, keeping the cost of guessing roughly constant. This is the dial a general-purpose hash simply does not have.
The three standard choices
- bcrypt is the long-standing, well-understood option, built on the Blowfish cipher with a configurable cost factor. A safe default where it is available.
- scrypt adds memory hardness: it deliberately consumes a tunable amount of memory, which blunts attackers using GPUs and custom chips, since those scale computation far more cheaply than memory.
- Argon2 won the Password Hashing Competition in 2015 and is the current recommendation for new systems. It is memory-hard with separate knobs for memory, time, and parallelism; the Argon2id variant is the usual choice.
Any of these is a reasonable choice; the cardinal rule is to use one of them, never a bare fast hash, and never to invent your own scheme.
The takeaway
Use SHA-256 (in the Hash tool) for checksums and integrity, where speed is a feature. For passwords, reach for bcrypt, scrypt, or Argon2, where slowness and memory cost are the whole point. The two jobs look similar and demand opposite tools.
This series, in order
This article opens the series Storing passwords. It names the tools; the parts explain why they are the right ones, attack first and defence after: the two ways to reverse a hash, the salt that ruins precomputed tables, the keyspace arithmetic of brute force, the slow functions that cut an attacker's rate, and a short decision guide.
- Brute Force vs Lookup Tables: Two Ways to Reverse a Hash. Precomputed tables against guess-and-check: the two families of search, trading storage for computation in opposite directions.
- Why Salting Defeats Precomputed Tables. A unique random value per password, and why it destroys the economics of lookup services and rainbow tables.
- Keyspace, Entropy, and Crack Time. Keyspace against hashing rate: why a few more characters move a secret from seconds to millennia.
- Slow KDFs: bcrypt, scrypt, and Argon2. Making each guess deliberately expensive and tunable, the defence salting cannot provide against a targeted attack.
- Choosing a Password Hash. The algorithm, the parameters and the mistakes to avoid, aligned with and guidance.