Plaintext Storage of a Password

A user's password is stored in a form that can be recovered as the original plaintext - stored directly with no hashing at all, or stored with reversible encryption instead of a one-way hash. This is distinct from merely weak password hashing (a fast, unsalted hash that's crackable but not directly reversible): here, the original password itself is recoverable by whoever can read the storage, full stop, which is what a password-reset flow that emails back your actual current password rather than a reset link is direct proof of.

How a password is stored server-side is invisible from outside - the only externally observable signal is an application behavior that implies plaintext storage, most reliably a password-reset or "forgot password" flow that emails or displays the actual existing password rather than issuing a new reset link or temporary token.

The behavioral signal, a password reset that returns or emails back the actual password, is directly testable by checking the reset flow's response for a token or secret leaking through, though that only proves a leak, not the underlying storage format. Direct confirmation of how passwords are actually stored requires source or database access.

Tip: This is almost always found through code or configuration review of the actual storage and hashing implementation, rather than through any external test — the stored value looks the same from outside regardless of whether it's properly hashed, so the only reliable check is reading the code that produces it.

Real-World Impact

How passwords are stored determines the entire blast radius of a future database breach. Plaintext storage or a recoverable ("encrypted, not hashed") format means a single database compromise hands over every user's actual password immediately, with no cracking effort required at all. Weak hashing, a fast general-purpose hash without a per-user salt, or an outdated algorithm, means the same breach still requires attacker effort, but often not very much: modern GPU-based cracking makes short work of unsalted or fast-hashed password databases at scale.

Because of widespread password reuse across services, the damage from a poorly-stored password database extends well beyond the breached application itself — leaked credentials get tested ("credential stuffed") against banking, email, and other higher-value targets, which is why this class is treated as high-severity even when the breached application itself holds low-value data.

Insufficiently random values in adjacent systems, password-reset tokens, session identifiers generated with a weak or predictable source, compound the same underlying risk: even a properly-hashed password becomes irrelevant if the reset flow around it can be predicted instead.

Prevention and Secure Design

Preventing Plaintext Storage of a Password takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Hash with a modern, purpose-built algorithm. Use bcrypt, scrypt, or Argon2 with a per-user salt — never plaintext, never reversible encryption, and never an unsalted or fast general-purpose hash like unsalted SHA-256/MD5.

Never store recoverable passwords, even for legitimate-sounding reasons. A "recoverable" format exists so support can retrieve a forgotten password directly — the correct flow is always a reset, not a retrieval, and that distinction alone prevents this class.

Use a cryptographically secure random source for anything security-relevant. Password-reset tokens, session identifiers, and similar values need to come from a CSPRNG, not a general-purpose or predictable random function.

Rate-limit and expire reset tokens tightly. Even a well-generated reset token should have a short expiry and single-use enforcement, so a leaked or predicted token has a narrow window of usefulness.

Plan for algorithm migration. Hashing recommendations shift over time (work-factor increases, algorithm deprecation) — build the storage schema to support re-hashing on next login rather than assuming today's choice is permanent.