Security
Password hashing: multiple-choice review
Six questions that cut across the whole unit. Each mirrors a real decision — what to ship in signup code, how to read a breach, which knob to turn — not a definition to recite.
Confirm you can connect the threat model (offline cracking), the defenses (slow + salted + memory-hard), the named parameters, and the production footguns — the synthesis the lesson built toward.
Your users table leaks with passwords stored as sha256(salt + password), salt unique per user. How bad is it?
A teammate proposes both a salt and a pepper. Where does each live, and why two?
Why does memory-hardness (Argon2id, scrypt) matter more than raw CPU slowness (e.g. high-iteration PBKDF2) against a real attacker?
You must store passwords for brand-new code with no FIPS constraint. Which choice and parameters?
An auth-bypass report says two different long passphrases authenticate the same account, both stored with bcrypt. Root cause?
Your Argon2id parameters were tuned in 2020 to ~250 ms. Years later a review flags them. What's the standard migration, and how do you compare hashes at login?
The through-line is one threat model and one defense stack. The attack is offline cracking — a leaked hash column run at full hardware speed (~22 billion SHA-256/sec per GPU), which makes any fast hash the wrong tool. The defense is slow + salted + memory-hard: a per-user salt (not secret, beside the hash) to kill rainbow tables, a vetted KDF with named parameters (Argon2id m=19 MiB/t=2/p=1 preferred, bcrypt cost 10+ or scrypt N=2^17 acceptable, PBKDF2 only under FIPS), an optional pepper kept outside the DB, a work factor you raise on a schedule via rehash-on-login, and the library’s constant-time verify rather than a hand-rolled equality check. Watch bcrypt’s 72-byte truncation trap.