CWE-261 Weak Encoding for Password: Base64 Is Not Protection

CWE-261 states it in one line: obscuring a password with a trivial encoding does not protect the password.

How it happens

MITRE describes the usual story. A password sits in plaintext in a properties or configuration file. A programmer notices and tries to fix it by running the password through an encoding function such as base 64. The file no longer shows the word at a glance, so it feels fixed.

It is not. Encoding is a format change, not a lock. Anyone can reverse it in one line:

import base64
print(base64.b64decode("cGFzc3dvcmQxMjM=").decode())  # password123

There is no key and no secret. The same is true of other trivial encodings, such as hex or simple character swaps.

MITRE's observed example is CVE-2022-45099, a network attached storage product that used weak encoding for a password.

What an attacker gains

The record lists access control: gaining privileges or assuming an identity. Whoever reads the file can decode the password and use it.

How to find it

MITRE lists automated static analysis. By hand, look for base 64 style strings next to keys named password, secret or token, and for encode calls applied to credentials.

How to fix it

The record gives one mitigation: passwords should be encrypted with keys that are at least 128 bits in length for adequate security. Real encryption only helps if the key is protected well, so the better design question is why the password has to be stored where the application can read it.

• If you only need to verify a user's password, store a salted one way hash instead.
• If your software must present a password to another system, keep it in a secret manager or similar protected store and load it at runtime.
• Do not call encoding a security control in design documents.

Why people reach for encoding

Encoding feels like progress. The password no longer appears as readable text in a file, and a casual look will not reveal it. That is the problem, because the only attacker it stops is someone who is not trying.

The distinction to hold onto is between hiding and protecting. Hiding changes how data looks. Protecting changes who can read it. A trivial encoding does the first and not the second, since the method is public and no key is needed.

When you find an encoded password during review, ask the same question you would ask of a plaintext one: does the application really need to read this value back? If it only verifies logins, replace it with a salted one way hash. If it must be presented to another system, move it into a protected secret store. Either way, the encoding step can go.

Quick check

Sources

• MITRE CWE-261