Hashing and Salting Passwords

The Hollow Oak Books website lets customers create accounts. If the site's database were ever stolen, what would the thief find in the password column? If the answer is "the passwords", every customer who reused theirs elsewhere is in trouble. The right answer is "salted hashes".

The rule

Store a salted hash, never the password: easy to check, hard to reverse.

A hash function turns any input into a fixed-length fingerprint:

• One-way — you cannot run it backwards to get the input.
• Deterministic — the same input always gives the same output.
• Sensitive — change one character and the output changes completely.

Here are the first 16 characters of SHA-256 fingerprints, just to show the idea:

At signup the site stores the hash. At login it hashes what was typed and compares. The password itself is never stored.

Hashing alone has a weakness: identical passwords give identical hashes, and attackers keep huge precomputed lists of hashes for common passwords. A salt fixes this. It is a random value, unique to each user, added to the password before hashing and stored beside the hash:

Same password, different salts, different hashes. Precomputed lists become useless and each account must be attacked separately.

Finally, real systems use slow hash functions made for passwords, such as Argon2, bcrypt or scrypt, not a fast one like SHA-256, so every guess costs an attacker real time.

Hashing is not encryption. Encryption can be undone with the key; a hash is not meant to be undone at all.

The shortcut

To judge any password storage, ask three questions: Is it hashed? Is it salted per user? Is the hash slow? Three yeses is good practice.

The trap is thinking a salt must be secret. It is stored in plain view; its job is to be unique, not hidden.

Drills

Answer fast — trust the rule.

Remember

• Store a salted hash, never the password.
• Check: hashed, salted per user, slow hash. Three yeses.
• Trap: storing plain or reversibly encrypted passwords, or thinking salts must be secret.