Security
Password hashing: free-recall review
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the material stick.
Reconstruct the unit’s core mechanisms — why fast hashes lose, what a salt and a pepper each do, why memory-hardness beats raw slowness, how the work factor migrates, and why you never roll your own compare — without looking back at the lesson.
- 01Why is a fast general-purpose hash like SHA-256 the wrong tool for storing passwords, even with a per-user salt?
- 02What is the difference between a salt and a pepper, and where does each one live?
- 03Why does memory-hardness cripple an attacker more than simply raising a CPU-bound iteration count?
- 04Name the three accepted modern algorithms with their OWASP parameters, and say when PBKDF2 is the right call.
- 05What is bcrypt's 72-byte trap, how has it caused real auth bypasses, and what is the correct fix?
- 06How do you keep the work factor current over time, and why must password comparison be constant-time?
If you could reconstruct each answer from memory, you hold the unit’s spine: the defended attack is offline cracking at full hardware speed, which makes fast hashes the wrong tool; a per-user salt (public, in the row) defeats rainbow tables while a pepper (secret, outside the DB) defends a DB-only leak; memory-hardness beats raw slowness by attacking GPU parallelism; the accepted algorithms are Argon2id (preferred), scrypt, and bcrypt (with PBKDF2 only under FIPS), each with named OWASP parameters; bcrypt’s 72-byte truncation is a real footgun; and the work factor rises on a schedule via rehash-on-login, with every comparison done in constant time by the library, never by hand.