Identification and Authentication Failures: Proving Who You Are

Once ranked second as "Broken Authentication," this category was renamed to Identification and Authentication Failures and moved to seventh in 2021 — a demotion that reflects better framework defaults, not a solved problem. It covers the whole chain of confirming identity: how a user proves who they are, how that proof is stored, and how the resulting session is protected. When any link fails, an attacker becomes someone else.

Authentication answers "are you who you say you are?" and identification is the claim that precedes it. The failures in this category let an attacker either guess their way to a valid identity or hijack one that has already been established. They cluster around three moments: the credential, the session, and the recovery flow that bypasses both.

Credential weaknesses

The most familiar failure is permitting weak or breached credentials. Applications that allow trivial passwords, do not check them against known-compromised lists, or lack any protection against automated guessing invite two related attacks: credential stuffing, replaying username-password pairs leaked from other breaches, and brute forcing, trying many passwords against one account. Without rate limiting, lockouts, or multi-factor authentication, both scale cheaply.

Session weaknesses

Even a perfect login is undone by a weak session. Predictable session identifiers, tokens exposed in URLs, sessions that never expire, or identifiers that are not rotated after login all let an attacker ride an authenticated session they did not earn. Session management is authentication's forgotten half: the credential is checked once, but the session token stands in for it on every subsequent request.

Strengthening authentication

• Implement multi-factor authentication. It is the single most effective control against stuffing and brute force, because a stolen password is no longer sufficient.
• Check passwords against breach corpora and follow current guidance: length over arbitrary complexity, no forced periodic rotation without cause.
• Rate-limit and monitor login attempts, apply progressive delays or lockouts, and alert on stuffing patterns.
• Generate strong, random session identifiers server-side, rotate them after login, set them as secure, HttpOnly cookies, and expire them.
• Harden account recovery. A weak reset flow is a side door around every other control; secure it with the same rigour as login.
• Never ship default or hard-coded credentials.

Authentication is the front door of nearly every application, which is why its failures are so consequential and so relentlessly probed. The controls are well established; the gaps come from the flows teams forget to secure — the password reset, the long-lived session, the forgotten legacy login. Finding those forgotten paths, before an attacker does, is the work this category demands.