LOGBOOK

HELP

Quiz Entry - updated: 2026.07.30

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).

Password storage from worst (plaintext) to best (salted, peppered Argon2)

* Worst to best: plaintext leaks everything, encryption just moves the key problem, a plain fast hash falls to GPUs and rainbow tables, and a salted+peppered Argon2 hash resists both. *

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 red flag — 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.

Go deeper:

From Quiz: ISF / Symmetric Cryptography | Updated: Jul 30, 2026