Overview
How an application stores passwords determines what happens if its database is ever breached. Storing them correctly — as salted, slow cryptographic hashes — is one of the most important defensive practices in web security. This lesson covers password storage concepts.
Learning objectives
- Explain why passwords must never be stored in plaintext or reversibly.
- Describe hashing, salting, and slow (adaptive) hash functions.
- Identify appropriate password-hashing approaches.
Core concept
Passwords must be stored as the output of a one-way cryptographic hash, never as plaintext or reversible encryption. Key ideas:
- Hashing — a one-way function; you store the hash and verify by hashing the submitted password and comparing.
- Salting — a unique random value added per password so identical passwords produce different hashes and precomputed (rainbow-table) attacks fail.
- Slow / adaptive hashing — purpose-built password hashes (such as bcrypt, scrypt, Argon2, PBKDF2) are deliberately computationally expensive to slow brute-force cracking. General-purpose fast hashes (like plain MD5/SHA-256) are not suitable for passwords.
How it works
At registration, the server generates a random salt, hashes the password with a slow algorithm, and stores the salt and hash. At login, it hashes the submitted password with the stored salt and compares. Because the hash is one-way, the original password cannot be recovered from storage; the salt defeats rainbow tables and makes each hash unique; and the slow function means that even if hashes are stolen, cracking them is expensive and time-consuming, buying time and protecting weak-but-not-trivial passwords.
Practical example
A secure system stores, per user, a random salt and a bcrypt/Argon2 hash of their password. If the database is breached, attackers get only slow, salted hashes — each must be cracked individually and slowly, so strong passwords remain safe and users have time to change credentials. Contrast a system storing plaintext or unsalted MD5: a breach instantly exposes every password (plaintext) or allows fast, mass cracking via rainbow tables (unsalted fast hash).
Cybersecurity relevance
Password storage is a top defensive concern because database breaches are common, and the storage method decides the fallout. Plaintext or reversible storage is catastrophic; unsalted or fast hashes enable mass cracking. Proper salted, slow hashing (bcrypt/scrypt/Argon2/PBKDF2) limits damage and is an expected standard. Assessments check for weak storage indicators; the topic also connects to why users should not reuse passwords (credential stuffing) and to breach response.
Common mistakes
- Storing plaintext or reversibly encrypted passwords — a breach exposes them all.
- Using fast general-purpose hashes (MD5/SHA-256) or no salt, enabling rainbow-table/mass cracking.
- Rolling a custom scheme instead of a vetted adaptive password hash.
Key takeaways
- Passwords must be stored as one-way hashes, never plaintext or reversible encryption.
- Use a unique per-password salt (defeats rainbow tables) and a slow/adaptive hash (bcrypt, scrypt, Argon2, PBKDF2) — not fast hashes like MD5/SHA-256.
- Storage method decides breach impact; proper salted slow hashing limits damage and is an expected security standard.
Check your understanding
- Why is a salt necessary even when passwords are hashed?
- Why are slow/adaptive hash functions preferred over fast general-purpose hashes for storing passwords?