Safeguard
Application Security•

CWE-308 Use of Single-Factor Authentication: Why One Factor Fails

When one stolen secret equals full access, a leak ends the game. Learn where single-factor design hurts most and how independent factors limit the damage.

Safeguard Security Team
2 min read

CWE-308 applies when a product uses an authentication method with a single factor, such as a password, in a security context that should require more than one.

The key words are "should require more." A forum login may be fine with a password. An admin console, a payment approval or a remote management interface is a different matter.

How it happens

Single-factor design is usually the default, not a decision. Teams ship a password login because it is quick, and nobody revisits it when the thing it protects grows in value.

It also appears in a quieter form: a second factor exists but can be skipped. MITRE's observed example is CVE-2022-35248, where a chat application skipped validation when Central Authentication Service (CAS) was enabled, which effectively removed the second factor from two-factor authentication. The product claimed two factors and delivered one.

What an attacker gains

If the secret in a single-factor scheme is compromised, full authentication is possible. MITRE lists this as a bypass of a protection mechanism. Passwords leak through phishing, reuse across sites, malware and weak storage, so this is not a rare event.

How to find it

The record lists no detection methods. A design review is the right tool:

  • List every login surface and ask what a stolen password alone would allow.
  • Pay special attention to administrative, remote access and high-value actions.
  • Test each alternate login path, such as single sign-on, API keys and recovery flows, to confirm each enforces the same factors.

How to fix it

MITRE's advice is to use multiple independent authentication schemes, so that if one is compromised the system is still likely safe. If several schemes are possible, implement them and require them, especially when they are easy to use.

  1. Require a second factor for privileged and sensitive operations.
  2. Make the factors independent, so one theft or one breach does not yield both.
  3. Enforce the second factor on every path, including federated login and recovery.
  4. Test the paths with deliberate bypass attempts, as the CAS case shows.

Quick check

Does a long password count as two factors?

No. Length makes guessing harder, but it is still one factor. If it leaks, access is complete.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.