Password Attacks & Cryptography · intermediate · ~11 min
State how passwords must be stored and why fast hashes fail.
Store passwords with a unique per-password salt and a slow, memory-hard KDF (Argon2 > scrypt > bcrypt) tuned via a work factor; optionally a separately-stored pepper. Fast hashes (MD5/SHA-256) are crackable at billions/sec; plaintext or unsalted fast hashes are serious findings.
Password storage determines whether a database breach becomes mass account takeover. Recognising fast/unsalted/plaintext storage and prescribing salted slow KDFs with a sensible work factor is a frequent, high-impact recommendation.
Salt. Unique per password; defeats rainbow tables. Slow KDF. Argon2/scrypt/bcrypt, memory-hard, tunable cost. Work factor. Keep each guess ~tens of ms; raise over time. Pepper. Separate secret. Findings. Plaintext, fast/unsalted hashes, global salt.
Passwords need a purpose-built approach — general-purpose fast hashes are exactly wrong.
SHA-256 is designed to be fast, so an attacker with a leaked database computes billions of guesses per second on a GPU. Fast = easy to crack.
Tune the cost so a login takes ~tens of milliseconds today, and raise it over time as hardware improves. This is the dial that keeps slow hashes slow.
Plaintext passwords, fast unsalted hashes (MD5/SHA-1/SHA-256), or a single global salt are serious findings — a database leak becomes mass account compromise. Recommendation: migrate to Argon2/bcrypt with per-password salts and an appropriate work factor.
Correct password storage means per-password salts plus a slow, memory-hard KDF (Argon2/bcrypt) with a maintained work factor — the opposite of a fast hash. Fast, unsalted, or plaintext storage turns a DB leak into mass compromise.