CWE-312 is the weakness of storing sensitive information in cleartext inside a resource that might be accessible to another control sphere. In plain words: the secret is written down as it is, in a place someone else may be able to read.
Every kind of product can do this, and MITRE lists platforms as not language specific, cloud computing, ICS/OT and mobile. Config files, databases, logs, backups, cookies and storage buckets are the usual hiding places.
How it happens
Cleartext storage is usually convenience. A password in a config file means no extra setup. A token in a database column means no key management. A credential in a cookie means no server-side session. Each choice works until someone gets read access by any route, such as a backup copy, a misconfigured bucket, a stolen laptop, a second vulnerability or a curious insider.
MITRE's observed examples:
- CVE-2022-26390: a wireless battery product stores credentials and Personal Health Information (PHI) without encryption.
- CVE-2022-30275: a Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
- CVE-2009-2272: a password and username stored in cleartext in a cookie.
- CVE-2009-1466: a password stored in cleartext in a file with insecure permissions.
Encoding does not help. MITRE notes that even when information is encoded so that it is not human-readable, certain techniques can determine which encoding is used and decode it.
# Vulnerable: password saved as given
db.execute("INSERT INTO users (email, password) VALUES (?, ?)", (email, password))
# Better for user passwords: store a salted, slow hash, never the password
from argon2 import PasswordHasher
ph = PasswordHasher()
db.execute("INSERT INTO users (email, password_hash) VALUES (?, ?)", (email, ph.hash(password)))
User login passwords should be hashed so they cannot be recovered. For secrets your service must use later, such as an API key for another system, encrypt them and keep the key outside the data store.
What an attacker gains
An attacker with access to the system can read sensitive information stored in cleartext. The listed impact is loss of confidentiality through reading application data. Stolen credentials then open other doors, since people and services reuse them.
How to find it
MITRE says static analysis (SAST) can find some instances by modeling data flow in source or compiled code. A secrets scanner finds the most common form, which is credentials committed to repositories and config. By hand:
- Open the database and look at the columns that should be secret.
- Read your config files, environment dumps, logs and crash reports.
- Inspect cookies and local storage in the browser.
- Check backups and snapshots, which hold copies of everything above.
How to fix it
- Do not store what you do not need. The safest secret is one you never kept.
- Hash user passwords with a slow, salted algorithm designed for passwords.
- Encrypt other sensitive data at rest with well-vetted algorithms, and keep keys separate from the data.
- Use the provider's controls in the cloud. MITRE says to use the cloud provider's controls to encrypt data at rest in S3 buckets, Azure blobs and Google Cloud Storage.
- Consider layered encryption where required. MITRE notes that in some environments "double encryption," at both the software and hardware layer, may be needed, and the developer may be solely responsible for both layers.
- Keep secrets out of source control and rotate any that were exposed.
- Restrict permissions on the files and stores that must hold sensitive values.
Try it yourself
This demo walks through secrets scanning, which finds credentials that were stored in plain view.
Click through it at your own pace, or open it full screen.
Quick check
Is a secret safe if the database is only reachable internally?
Not safe enough. Backups, insiders, a second vulnerability or a misconfiguration can all expose it. Encrypt or hash anyway.
Does base64 count as protection?
No. It is a reversible encoding, not encryption.
