Loading module...

Authentication Failures | Top 10 Dev Training

OWASP-07

Authentication Failures

Confirmation of the user's identity, authentication, and session management is critical.

Audio overview (optional)

AI-generated summary. The Read tab has the full written content, which is the primary source and what the quiz is based on.

Transcript

Authentication failures is where your system's front door lives. Get this category wrong and the rest of your security doesn't matter, because attackers don't have to bypass your controls. They just log in as someone else. The category holds steady at number seven in 2025, covering thirty six distinct CWEs, and despite significant improvements from standardized frameworks, it remains a critical vulnerability area.

Let's talk about what authentication failures actually look like in 2026.

Credential stuffing. Attackers take lists of usernames and passwords breached from other sites and try them against yours. This works because password reuse is rampant. If a user's password was compromised at a breach three years ago, and they still use it, the attacker gets in.

Hybrid credential stuffing is the newer, more effective variant. Instead of trying the exact password, the attacker tries variations based on predictable human behavior. "Winter twenty twenty five" becomes "Winter twenty twenty six." "ILoveMyDog six" becomes "ILoveMyDog seven" or "ILoveMyDog five." Without defenses against automated attempts, your application becomes a password oracle that tells the attacker which variations work.

Password spraying. Rather than trying many passwords against one account, the attacker tries a handful of very common passwords against many accounts. This evades simple lockout policies that trigger after five failed attempts for one user, because each individual account only sees one or two attempts.

Weak credential recovery. Security questions, as we discussed in the previous module, cannot be made safe. But plenty of applications still use them. Plenty more have password reset flows that leak information about whether an email is registered, which turns the reset endpoint into an account enumeration tool.

Poor password storage. Plaintext passwords, obviously bad. Encrypted passwords, also bad if the encryption key is available to the attacker. Fast unsalted hashes like MD5 or SHA one, crackable in minutes with modern GPUs. Even bcrypt with outdated work factors is no longer strong enough against well-resourced attackers.

Session management issues. Session IDs exposed in URLs, where they end up in browser history and server access logs. Session IDs that don't rotate after login. Sessions that never expire on logout or inactivity. Single sign-on systems where logging out of one application doesn't log out of the others, leaving mail, documents, and chat authenticated after the user thought they were signed out.

Hard-coded credentials. Passwords in source code, in configuration files, in Docker images. Anyone who can read the repository can authenticate.

So how do you defend against authentication failures? Five patterns that together cover most of the category.

First, MFA should be the default, not an optional add-on. Any application handling sensitive data without MFA as an option is behind the curve, and any admin account without MFA required is a breach waiting to happen. TOTP is the floor. Hardware security keys, WebAuthn, and passkeys are the direction.

Second, stop the bad password practices that never worked. NIST 800-63 guidelines are clear. Minimum eight characters, maximum at least sixty four. No mandatory complexity rules. No mandatory periodic password changes. Check against databases of breached passwords before accepting a new one. Password complexity and rotation policies, once considered best practice, actively encourage users to reuse passwords and pick weak ones. The science is settled. Stop requiring them.

Third, rate limit failed login attempts. Every failure should be logged. A spike in failures across many accounts is an active attack. Alert on it.

Fourth, treat credential recovery with the same rigor as login. Same messaging for all outcomes to prevent account enumeration. Email-based reset links that expire quickly. MFA required before the password can be reset. The recovery flow is often the weakest link, and attackers know it.

And fifth, implement session management carefully. Generate a new, random, high-entropy session ID after login. Never expose it in URLs. Invalidate it on logout, on idle timeout, and on absolute timeout. For SSO, make sure single logout actually works.

Authentication is your front door. Modern frameworks give you most of the tools. The remaining gap is always discipline. Use the tools, follow the current guidelines, and stop assuming the attackers are using techniques from five years ago.

Quiz & Certification

Training content is freely available. Sign in and get a training credit to take quizzes, track progress, and generate compliance reports.

Attestation not yet available

Complete and pass every module quiz in this course to unlock the final attestation. Once all modules are done, this tab will open for signing.

A07:2025 - Authentication Failures

Overview

Authentication failures occur when an attacker tricks a system into recognizing an invalid or incorrect user as legitimate.

Impact: Maintains position at #7 with 36 CWEs. Despite benefits from standardized frameworks, authentication remains a critical vulnerability area.

Common Vulnerabilities

Automated Attacks

Credential Stuffing: Using breached lists of valid usernames and passwords
Password Spray Attacks: Trying variations of spilled credentials (Password1!, Password2!, Password3!)
Brute Force: Automated attacks not quickly blocked

Weak Passwords

Permits default, weak, or well-known passwords ("Password1", "admin/admin")
Allows users to create accounts with known-breached credentials

Weak Credential Recovery

Uses weak or ineffective credential recovery and forgot-password processes (knowledge-based answers cannot be made safe).

Poor Password Storage

Uses plain text, encrypted, or weakly hashed passwords in data stores.

Missing MFA

Missing or ineffective multi-factor authentication, or weak fallbacks when MFA unavailable.

Session Management Issues

Exposes session identifier in URL, hidden field, or insecure location
Reuses same session identifier after successful login
Doesn't correctly invalidate sessions/tokens during logout or inactivity
Doesn't correctly assert scope and intended audience of credentials

Hard-coded Credentials

Use of hard-coded passwords or credentials (CWE-259, CWE-798).

JWT Signing Algorithms

Most modern web and mobile applications move state across services using JSON Web Tokens (JWTs). A JWT is a signed claim: the server signs a payload (user ID, expiration, roles) with a key, the client stores the token, and any service that holds the verification key can confirm the token is authentic without a round-trip to the auth server. JWTs are signed, not encrypted. The payload is base64url-encoded and readable by anyone who sees the token.

The signature is where authentication actually lives. The JWT header includes an alg field naming the signing algorithm, for example:

{"alg": "HS256", "typ": "JWT"}   ← symmetric: HMAC-SHA256 with a shared secret
{"alg": "RS256", "typ": "JWT"}   ← asymmetric: RSA signature, private key signs, public key verifies

Two classic attacks exploit careless verification:

Attack 1: `alg: none` acceptance

Early JWT libraries accepted "alg": "none" as a valid algorithm, meaning "this token is unsigned." An attacker crafts a token with {"alg":"none"} in the header, sets sub to the target user ID, omits the signature block entirely, and sends it. A library that trusts the header as authoritative accepts it and logs the attacker in as any user. This bug shipped in multiple mainstream libraries (notable early case: jwt-simple in 2015).

Attack 2: RS256 → HS256 algorithm confusion

The server is configured to verify with RS256 (asymmetric): the public key is, by definition, public and often exposed at a JWKS endpoint. If the verification code takes the algorithm from the token header instead of pinning it, an attacker flips the header to "alg":"HS256" (symmetric) and signs the token with the public key itself as the HMAC secret. A vulnerable library sees alg: HS256, grabs whatever key was configured for verification (the RSA public key bytes), treats those bytes as the HMAC secret, and computes a signature that matches what the attacker produced. The token passes verification.

This class of bug has been found repeatedly in the wild, including in widely-used libraries like jsonwebtoken (Node.js, CVE-2022-23529).

Mitigations

Pin the expected algorithm in the verification call. Never pass algorithms as "whatever is in the token header." Verify code should say explicitly: "this endpoint only accepts RS256" or "only HS256," and reject everything else including none.
Don't share the same key for multiple algorithms. Keep signing key material separated from any other key material the server uses.
Prefer asymmetric (RS256, ES256) for tokens that cross service boundaries. The signing key stays in one place (the auth server) and public verifiers can be updated without secret distribution.
Keep libraries up to date. The algorithm-confusion class has recurred across languages; verify your library is on a version that has patched it.
Validate every claim you rely on: exp (expiration), nbf, iss (issuer), aud (audience). An unexpired, correctly-signed token for the wrong audience is still a failure.

Real-World Attack Scenarios

Scenario 1: Hybrid Credential Stuffing

Attackers use lists of known username/password combinations and adjust passwords based on human behavior.

Attack: Changing 'Winter2025' to 'Winter2026', or 'ILoveMyDog6' to 'ILoveMyDog7' or 'ILoveMyDog5'.

Impact: More effective than traditional credential stuffing. Without defenses against automated threats, application becomes a password oracle to determine valid credentials.

Scenario 2: Password-Only Authentication

Most successful authentication attacks occur due to continued use of passwords as sole authentication factor.

Problem: Password rotation and complexity requirements (once considered best practices) encourage users to reuse passwords and use weak passwords.

Solution: Stop these practices per NIST 800-63 and enforce multi-factor authentication on all important systems.

Scenario 3: Improper Session Timeout

Application session timeouts aren't implemented correctly.

Attack: User uses public computer, closes browser tab instead of logging out. Another user (or attacker) uses same browser and accesses victim's authenticated session.

SSO Example: Single Sign-On session can't be closed by Single Logout (SLO). Logging out of one application doesn't log out of mail reader, document system, and chat system.

Impact: Unauthorized access to victim's account and data.

How to Prevent

Multi-Factor Authentication

Implement MFA to prevent automated credential stuffing, brute force, and stolen credential reuse attacks.

No Default Credentials

Do not ship or deploy with any default credentials, particularly for admin users.

Weak Password Checks

Test new or changed passwords against list of known-breached passwords
Implement password strength meter
Check against top 10,000 worst passwords

Modern Password Policies

Align password length, complexity, and rotation policies with NIST 800-63 guidelines:

Minimum 8 characters, maximum 64+ characters
No mandatory complexity requirements
No mandatory periodic password changes
Check against breached password databases

Account Enumeration Protection

Harden registration, credential recovery, and API pathways against account enumeration attacks using same messages for all outcomes.

Rate Limiting

Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks detected.

Session Management

Generate new random session ID with high entropy after login
Never expose session IDs in URLs
Securely store session IDs
Invalidate session IDs after logout, idle timeout, and absolute timeout
Implement proper Single Logout for SSO systems

Additional Resources

Content adapted from OWASP Top 10:2025, licensed under CC BY-SA 4.0