Overview
Password storage determines what happens if a credential database is breached — the single most consequential password-security decision. This lesson covers assessing how passwords are stored.
Learning objectives
- Explain why storage method is critical.
- Distinguish secure from insecure storage.
- Assess storage designs (defensively).
Core concept
Passwords must be stored as one-way cryptographic hashes, never as plaintext or reversible encryption. From an assessment perspective, the storage method sets the blast radius of a breach: plaintext or reversible storage means a breach exposes every password immediately; properly hashed (salted, slow) storage means passwords remain protected even if the database is stolen. Reviewing storage design (in an authorized audit of a credential store or its documentation/code) checks whether it follows secure practice.
How it works
In a secure design, the system stores a one-way hash (with a salt and a slow algorithm — next lessons) and verifies logins by hashing the input and comparing. An assessor evaluating storage looks for red flags: plaintext passwords, reversible encryption, or fast/unsalted hashing — all of which fail catastrophically on breach. This assessment is defensive and typically involves reviewing design, configuration, or code (in an authorized context), not attacking real credentials. The finding "passwords stored insecurely" is among the most serious in any assessment.
Practical example
Auditing a fictional credential store (as in this module's lab), the assessor examines how passwords are stored. Finding them stored reversibly (so they can be decrypted back to plaintext) is a critical weakness — a breach would expose all passwords directly. The recommendation is to migrate to salted, slow, one-way hashing. Conversely, a store using a proper adaptive hash with per-user salts would pass this check. The review focuses on the storage design, not on cracking anyone's password.
Cybersecurity relevance
Password storage is a top defensive concern because breaches are common and storage method decides the fallout — plaintext/reversible storage is catastrophic, while proper hashing limits damage. Assessments (design/code review, in authorized contexts) flag insecure storage as critical. This connects directly to the web-security authentication module's storage lesson. The takeaway is defensive: ensure one-way, salted, slow hashing. Testing is about evaluating the design, not attacking real credentials — which would be out of scope and harmful.
Common mistakes
- Storing passwords in plaintext or reversible encryption, catastrophic on breach.
- Using fast/unsalted hashing, enabling mass cracking (covered next).
- Assessing storage by attacking real credentials rather than reviewing the design.
Key takeaways
- Passwords must be stored as one-way, salted, slow hashes — never plaintext or reversible encryption.
- Storage method sets the blast radius of a breach; insecure storage is a critical finding.
- Assess storage defensively (design/code review in authorized contexts), not by attacking real credentials; this ties to the web-security authentication storage lesson.
Check your understanding
- Why is the password storage method the key factor in a credential-database breach's impact?
- How should password storage be assessed without attacking real credentials?