Cleartext Storage in a File or on Disk

Draft Variant
Structure: Simple
Description

This vulnerability occurs when an application writes sensitive data, such as passwords or personal information, directly to a file or disk without using encryption.

Extended Description

When sensitive data is stored in plain text, anyone with access to the file—or even the raw disk—can read it directly. This includes attackers who have gained system access, malicious insiders, or even system administrators performing routine maintenance. The risk isn't limited to standard file permissions; physical access to a storage device or the ability to read disk sectors can also expose the unprotected information. Even if the data appears scrambled or uses a simple encoding like Base64, it does not provide real security. Attackers can easily detect common encoding schemes and reverse them to recover the original cleartext. True protection requires strong, standard encryption with a securely managed key, not just obfuscation, to ensure data remains confidential both at rest and if the storage medium is compromised.

Common Consequences 1
Scope: Confidentiality

Impact: Read Application Data

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.)
Demonstrative Examples 1

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 5
CVE-2001-1481Cleartext credentials in world-readable file.
CVE-2005-1828Password in cleartext in config file.
CVE-2005-2209Password in cleartext in config file.
CVE-2002-1696Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
CVE-2004-2397Cleartext storage of private key and passphrase in log file when user imports the key.
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Architecture and Design
Taxonomy Mapping
  • PLOVER
  • Software Fault Patterns
Notes
TerminologyDifferent people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).