Password hashing & salting.
Store a fingerprint of the password, with grit mixed in so two alike never match.
A careful club never keeps a list of members’ actual keys. Instead it records a unique fingerprint of each key — enough to recognise the right one at the door, but useless for cutting a copy. Even if the records are stolen, the keys themselves were never written down.
That is how passwords should be stored. The site never keeps your raw password. It keeps a one-way fingerprint (a hash) that it can check against, plus a dash of random “salt” so that two people with the same password still get different fingerprints.
- Save it as-is? No.1
The cardinal rule: never store the raw password. Ever.
- 2
Store a one-way fingerprint instead — easy to make, impossible to reverse.
- 3
Mix in random “salt” first, so identical passwords get different fingerprints.
- Fingerprints match.4
At login, fingerprint the attempt the same way and compare. Match? You’re in.
- 5
Use a deliberately slow hash (bcrypt), so guessing billions is painfully expensive.
- …useless to me.6
A stolen database is now near-useless — just fingerprints, no keys.
Why salt matters
Without salt, the same password always hashes to the same value, so an attacker can precompute fingerprints for millions of common passwords (a “rainbow table”) and match them in bulk. A unique random salt per user breaks that: the attacker would have to redo all that work for every single account, which is no longer worth it. The salt is not secret — it is stored alongside the hash — it just makes each fingerprint one-of-a-kind.
Why slow is a feature
For most code, fast is good. For password hashing, fast helps the attacker, who wants to try billions of guesses. Purpose-built hashes like bcrypt, scrypt, and argon2 are deliberately slow and memory-hungry, and tunable to stay slow as hardware improves. One login taking a few milliseconds is invisible to you, but it makes mass guessing of a stolen database hopelessly expensive.