Quiz Entry - updated: 2026.07.14
What are the four approaches to storing passwords, ordered from worst to best?
Plaintext (catastrophic) → encrypted with a key (complicated) → plain hash (good) → salted, peppered, Argon2 (best).
| Approach | Rating | What's wrong / right |
|---|---|---|
| Plaintext | "Schlecht" (bad) | Any DB breach instantly leaks all passwords. Reused passwords compromise other sites. |
| Encrypted (e.g. AES) | "Kompliziert" (complicated) | The encryption key must be stored somewhere — and if the attacker who got the DB also gets the key, encryption was just a speed bump. Also: encryption is reversible, but you don't need reversibility for password checking. |
| Hashed | "Gut" (good) | Hash is one-way; the server stores H(password) and re-hashes on login. But fast hashes (SHA-256) are too easy to brute-force on a GPU, and rainbow tables trivially crack unsalted hashes. |
| Salted + peppered + Argon2 | "Besser" (better) | Defeats rainbow tables (salt) AND offline brute-force (Argon2's memory-hardness). The modern best practice. |
Why "encrypted" is actually worse than hashed:
- Encryption gives you reversibility, which password storage doesn't need.
- Storing the key alongside the DB defeats the point; storing it elsewhere just moves the problem.
- An attacker who compromises the application server gets both → everything decryptable.
Tip: "Encrypted passwords" in a breach announcement is a 🚩 — it usually means "we did something wrong but want it to sound good." Properly-stored passwords are hashed, not encrypted. The exception is using a hardware security module (HSM) as the key store, which legitimately keeps the encryption key out of the attacker's reach.