Storing Passwords in a Recoverable Format

Incomplete Base
Structure: Simple
Description

This vulnerability occurs when an application stores user passwords in a format that can be easily reversed or decrypted back to their original plaintext form. This practice, often called storing 'recoverable' passwords, defeats the core purpose of password protection. It allows anyone with access to the stored data—including attackers who breach the system or even malicious insiders—to obtain and reuse the actual passwords on other accounts, offering no real security advantage over storing them in plain text.

Extended Description

When passwords are stored in a recoverable format, such as using weak or reversible encryption instead of a proper one-way hash, the system inherently retains the ability to convert them back. This creates a single point of failure: if the storage is compromised or accessed by an unauthorized party, every password becomes immediately usable for account takeover and credential stuffing attacks across other services. The risk is identical to storing plaintext passwords, as the decryption key or method is typically accessible within the application's environment. From a security perspective, there is no legitimate operational need for developers or system administrators to retrieve a user's original password. Standard authentication should compare a one-way hash of the entered password against a stored hash. Any design that requires password recovery is flawed; a secure system should only offer a password reset function. Relying on reversible storage undermines user trust and system integrity, as it enables abuse by both external attackers and privileged insiders who can decrypt credentials at will.

Common Consequences 2
Scope: ConfidentialityAccess Control

Impact: Gain Privileges or Assume Identity

User's passwords may be revealed.

Scope: Access Control

Impact: Gain Privileges or Assume Identity

Revealed passwords may be reused elsewhere to impersonate the users in question.

Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: Architecture and Design
Use strong, non-reversible encryption to protect stored passwords.
Demonstrative Examples 2

ID : DX-59

Both of these examples verify a password by comparing it to a stored compressed version.

Code Example:

Bad
C
c

Code Example:

Bad
Java
java

//Diagnostic Mode* return(1);}

Because a compression algorithm is used instead of a one way hashing algorithm, an attacker can recover compressed passwords stored in the database.

ID : DX-43

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext.
This Java example shows a properties file with a cleartext username / password pair.

Code Example:

Bad
Java

Java Web App ResourceBundle properties file*

java
The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext.

Code Example:

Bad
ASP.NET
asp.net
Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.
Observed Examples 1
CVE-2022-30018A messaging platform serializes all elements of User/Group objects, making private information available to adversaries
References 1
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
Likelihood of Exploit

High

Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Taxonomy Mapping
  • CLASP
  • Software Fault Patterns
Notes
MaintenanceThe meaning of this entry needs to be investigated more closely, especially with respect to what is meant by "recoverable."