Storing Passwords in a Recoverable Format

Passwords are stored using reversible encryption (rather than a one-way hash) - recoverable back to plaintext by anyone with the decryption key, which is a narrower, encryption-specific instance of the broader plaintext-password-storage problem. Even though the stored value isn't literally plaintext at rest, it's functionally equivalent from a risk perspective: whoever controls the decryption key can recover every user's actual password on demand.

Storage format is an internal implementation detail invisible from outside. The clearest external signal - a password-reset flow that emails back the user's actual existing password rather than a reset link - is a strong behavioral proxy, but confirming the storage mechanism itself (reversible encryption specifically, vs. plaintext, vs. proper hashing) requires source or database access.

Checking whether the password-reset flow leaks a token or secret into its response is the closest externally observable proxy signal available. Confirming the actual storage format requires source-level review.

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 Storing Passwords in a Recoverable Format 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.