When your password shows up in a breach list, you might tell yourself: “the site encrypted my password, so it should be fine.” The truth is — the site shouldn’t know your password, and doesn’t need to.
From plaintext to slow hashes
- Plaintext — the password is stored as-is. RockYou (2009) leaked ~32 million plaintext passwords.
- Encryption — lock it in a safe with a key. Problem: the safe can be opened, the key lives on the same machine, and the same password produces the same ciphertext. Adobe (2013, 3DES-ECB) is the textbook case.
- Hashing — store only the “shredded” fingerprint; it can’t be reversed. Next login, shred again and compare.
- Fast hashes aren’t enough — precomputed dictionaries cover hundreds of millions of common passwords. LinkedIn (2012, unsalted SHA-1) had many passwords recovered within days.
- Salting — a unique random salt per user, so the same password yields different hashes. The salt isn’t secret; reusing one salt for everyone is the real danger.
- Slow hashing (adaptive) — deliberately slow: bcrypt / scrypt / Argon2, with a tunable cost that rises with hardware.
Three takeaways
- Hashing ≠ encryption (can’t reverse vs. can be unlocked);
- Always salt;
- Make it slow.
Engineering practice
- Use a standard slow hash: Argon2id (OWASP-recommended) / bcrypt / scrypt; PBKDF2 with high iterations.
- Salt ≥ 32 bits, tune cost upward over time (NIST SP 800-63B).
- Never write passwords to logs.
These practices come from building Autional, an open-core identity layer — https://www.autional.com
Reference: OWASP Password Storage Cheat Sheet, NIST SP 800-63B, RFC 9106 (Argon2), RFC 7914 (scrypt); cases: LinkedIn 2012, Adobe 2013, RockYou 2009.
Top comments (0)