Authentication Failures

What Are Authentication Failures?

Authentication failures (previously called "Broken Authentication" in OWASP 2017) sit at position A07 in the 2025 list. The category covers everything that goes wrong when an application tries to verify that you are who you claim to be — and gets it wrong. It includes weak login implementations, predictable session tokens, missing rate limits, flawed password reset flows, and JWT misconfigurations.

The reason this category exists as its own entry year after year is simple: authentication is hard to get right, and getting it wrong is catastrophic. When an attacker breaks authentication, they don't need an exploit chain or a zero-day. They just become you. They access your account, your data, your admin panel. Everything downstream depends on the assumption that your authentication layer is solid.

Attack Vectors in the Wild

Authentication failures aren't a single vulnerability — they're a family of related weaknesses. Let's go through the most common ones and how they actually get exploited.

Credential Stuffing

This is the attack that keeps giving. Users reuse passwords across dozens of services. When a database breach leaks millions of email/password combinations (Rockyou2024, Collection #1, etc.), attackers feed those credentials into login forms at scale. Automated tools like Snipr or OpenBullet can test thousands of credential pairs per minute against a target application.

What makes credential stuffing so effective is that it doesn't require any vulnerability in the target app per se. If 1% of a 10-million-record credential dump matches active accounts on your platform, that's 100,000 compromised accounts from one breach you didn't even cause.

# Typical credential stuffing fingerprint in access logs:
POST /api/login HTTP/1.1
Host: example.com
User-Agent: python-requests/2.28.0
# Thousands of requests from rotating IPs, same endpoint
# All with valid-looking email/password combinations
# Success rate 0.5-2% against a large user base

# What no rate limiting looks like:
[02:11:04] 200 POST /login from 45.12.x.x — admin@example.com:hunter2
[02:11:04] 401 POST /login from 45.12.x.x — user@example.com:Password1
[02:11:04] 401 POST /login from 193.x.x.x — bob@example.com:123456
# 4,800 requests in 60 seconds — zero lockouts

Brute Force and Password Spraying

Classical brute force — trying every combination — is mostly dead against modern systems because it triggers lockouts. Password spraying is more subtle: pick a few extremely common passwords (Password1!, Summer2024!, Welcome123) and try them against every account. You stay under lockout thresholds while covering enormous ground.

This works because enterprise environments often have predictable password patterns enforced by policies ("must contain a capital letter, number, and symbol") that push users toward easily-guessable formulas. An attacker who knows your password policy can narrow the search space dramatically.

Session Fixation and Hijacking

Session fixation happens when an attacker can force a known session ID onto a victim before authentication. If the application doesn't regenerate the session token on successful login, the attacker's pre-seeded session ID becomes authenticated the moment the victim logs in.

# Vulnerable login flow (session fixation):
# 1. Attacker gets a valid pre-auth session token
GET /login → Set-Cookie: session=ATTACKER_KNOWN_TOKEN; HttpOnly

# 2. Attacker tricks victim into using that token
#    (via URL parameter, XSS, or network manipulation)
# 3. Victim logs in — app authenticates session without regenerating it
# 4. Attacker now has an authenticated session

# Secure pattern — regenerate session on login:
session_regenerate(delete_old_session=True)
session.set('user_id', user.id)

Session hijacking is the broader category: stealing a valid session token via network interception (unencrypted HTTP), XSS that leaks cookies, or log injection. If session tokens are predictable or short, brute-forcing them directly is also viable.

Weak or Default Passwords

Applications that ship with default admin credentials (admin/admin, admin/password, root/root) are a perennial problem. Web admin interfaces — phpMyAdmin, routers, IoT devices, internal dashboards — often come with documented defaults that never get changed. Shodan continuously indexes these across the internet.

On the flip side, applications that don't enforce meaningful password policies allow users to set "123456" as their password. Without length minimums, complexity requirements, and checks against common password lists (like the haveibeenpwned API), your user base will collectively choose terrible passwords.

Missing or Bypassable MFA

Multi-factor authentication dramatically reduces account takeover risk — but only when implemented correctly. Common MFA failures include:

• OTP not invalidated after use — an intercepted one-time code can be replayed within its validity window
• OTP brute-forceable — 6-digit codes have only 1,000,000 possibilities; without rate limiting, they're bruteforceable in minutes
• MFA bypass via account recovery — the "forgot password" flow circumvents MFA entirely and sends a reset link to email
• Response manipulation — changing {"mfa_required": true} to false in a frontend response to skip the MFA step
• Race condition — submitting the MFA verification twice simultaneously, one of which succeeds before the token is invalidated

JWT Vulnerabilities

JSON Web Tokens are everywhere, and they're deceptively easy to misconfigure. The three most commonly exploited JWT flaws are:

Algorithm confusion (alg:none): Some JWT libraries will accept a token with "alg": "none" and no signature, treating it as valid. If your library hasn't patched this, an attacker can forge any payload by simply setting the algorithm to none and stripping the signature.

# Original JWT header:
{"alg": "HS256", "typ": "JWT"}

# Attack — strip signature and set alg:none:
{"alg": "none", "typ": "JWT"}
# Payload with modified claims (role:admin, etc.)
# No signature required — accepted by vulnerable libraries

# RS256 → HS256 confusion attack:
# Server uses RSA private key to sign (RS256)
# Public key is, well, public
# Attacker: re-signs token with the public key using HS256
# Vulnerable server: verifies HS256 signature using the same public key → valid!

Weak signing secrets: HS256 tokens signed with a guessable secret (like "secret", "password", or the application name) can be cracked offline using tools like hashcat or jwt-cracker. Once the secret is known, the attacker can forge arbitrary tokens.

Missing expiration or revocation: JWTs are stateless by design, but that means a stolen token is valid until it expires — and if expiration is set to a month or year, that's a long window. Applications that don't maintain a session/revocation store can't invalidate tokens after logout or password change.

Password Reset Flaws

The password reset flow is often where strong authentication goes to die. Classic vulnerabilities include:

• Predictable reset tokens — tokens based on timestamps or user IDs that an attacker can compute without being sent the link
• Token not expiring — a reset link from 2019 still works today
• Host header injection — attacker manipulates the Host header so the reset email contains a link pointing to their server
• Token leaking in Referer — if the reset page includes analytics or third-party scripts, the token in the URL may leak via the Referer header
• No invalidation after use — the same reset token can be used multiple times

# Host header injection in password reset:
POST /forgot-password HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded

email=victim@example.com

# Result: victim receives email with link:
# https://attacker.com/reset?token=abc123
# Victim clicks → token delivered to attacker

Testing for Authentication Failures

A thorough authentication test goes beyond just trying admin/admin. Here's how to approach it methodically.

Rate Limiting and Lockout Testing

The first thing to check is whether the login endpoint rate-limits requests. Use Burp Suite's Intruder or a simple script to send 50 failed login attempts in quick succession. Check whether you get locked out, see CAPTCHAs appear, or whether requests continue succeeding at the same rate. Also test whether lockouts apply per-account, per-IP, or both — IP-based lockouts are trivially bypassed with rotating proxies.

# Quick rate limit check with curl:
for i in {1..20}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://target.com/login \
    -d '{"email":"test@test.com","password":"wrongpass"}'
done
# All 200s or 401s = no rate limiting
# 429 after N requests = rate limiting present

Session Token Analysis

Collect 20-30 session tokens from the same application (log in and out multiple times, or use multiple accounts). Analyze them for patterns:

• Are they truly random, or do they contain encoded user IDs / timestamps?
• Do they change after privilege escalation or role changes?
• Are they invalidated server-side after logout?
• Are they sent over HTTP anywhere (check redirects)?
• Are cookies marked Secure, HttpOnly, and SameSite?

# Check if session persists after logout:
# 1. Log in, capture cookie/token
# 2. Log out via the app
# 3. Replay the old token
curl -H "Cookie: session=OLD_TOKEN" https://target.com/api/me
# If you get 200 and user data = session not properly invalidated

JWT Testing

For JWT-based applications, start with jwt.io to decode tokens and understand the structure. Then:

1. Try setting alg to none and removing the signature
2. Try changing alg from RS256 to HS256 and signing with the public key
3. Run hashcat against the token with a common wordlist: hashcat -a 0 -m 16500 token.txt rockyou.txt
4. Check the exp claim — what's the token lifetime?
5. Modify claims (role, user_id, admin) and send the modified token — does the app validate the signature?

Password Reset Flow

Request a password reset and capture the token. Then:

• Try the token 24 hours later — does it still work?
• Try the same token twice — does the second use succeed?
• Check if the token appears anywhere in the URL (Referer leak risk)
• Send the request with Host: attacker.com and check whether the reset email links to your server
• Observe the token entropy — is it a short number, UUID v1 (timestamp-based), or proper randomness?

Real-World Examples

Okta 2023 breach: A customer support system credential was compromised through a third-party contractor. The session didn't require MFA due to a misconfiguration, giving attackers authenticated access to view customer data for 1Password, BeyondTrust, and Cloudflare. The underlying cause was insufficient session controls in a support portal — a textbook authentication failure.

23andMe credential stuffing (2023): Attackers used credentials from other breaches to log into approximately 14,000 23andMe accounts directly. Through the DNA Relatives feature, they could then scrape data from an additional 6.9 million users whose profiles were linked. No vulnerability in 23andMe's code — just users reusing passwords and no MFA enforcement.

Rockstar Games (GTA 6) internal systems: Early access to development builds and internal Confluence pages was obtained in 2022 by compromising an employee's Slack session via social engineering. The session token wasn't bound to device fingerprint or IP, making it portable once extracted.

Defense and Remediation

If you're building or securing an application, here's what actually moves the needle:

• Use a proven authentication library — don't roll your own. Passport.js, Spring Security, Django's auth framework, and similar battle-tested solutions handle most edge cases by default.
• Rate limit login endpoints — implement exponential backoff and IP-based rate limiting. Consider account lockout after N failures, but use temporary lockouts to avoid denial-of-service.
• Enforce MFA — make it the default, not optional. TOTP is better than SMS (SIM swapping), hardware keys better still.
• Check passwords against breach lists — the haveibeenpwned API lets you check passwords against billions of known-compromised credentials without sending the actual password.
• Regenerate session tokens on privilege change — every login, role change, or privilege escalation should issue a fresh token and invalidate the old one.
• Set secure cookie flags — always use Secure, HttpOnly, and SameSite=Strict or Lax on session cookies.
• Implement proper JWT lifecycle — short expiry (1-24 hours), server-side revocation store for logout, strong secret (256-bit random), validate all claims.
• Use constant-time comparison for token/password verification — timing attacks can leak information through response latency differences.

How Automated Scanners Find Authentication Issues

Authentication testing is one area where automated scanners can contribute meaningfully, though human judgment remains essential for understanding context. A good scanner will:

• Test login endpoints for rate limiting by sending automated bursts of failed attempts
• Attempt default credentials (admin/admin, admin/password, test/test) across discovered admin interfaces
• Decode and analyze JWT tokens for weak algorithms, missing expiration, and guessable secrets
• Check session cookie security attributes (Secure, HttpOnly, SameSite)
• Test whether sessions remain valid after logout
• Probe password reset flows for Host header injection
• Check for user enumeration via response differences between valid/invalid accounts

The AISEC scanner runs all of these checks as part of a comprehensive authentication audit. It uses a real browser (Playwright) to discover login forms, test session behavior, and trace authentication flows end-to-end — the kind of testing that catches issues passive scanners miss entirely.

Summary

Authentication failures sit at A07 in OWASP Top 10:2025, but don't let the rank fool you — a broken authentication implementation is often the fastest path to complete account takeover. Credential stuffing uses your users' recycled passwords against them at scale. Session fixation and hijacking let attackers silently inherit authenticated sessions. JWT misconfigurations hand attackers the keys to forge their own identity tokens. And forgotten edge cases in password reset flows frequently provide a low-friction path that bypasses all your other security controls.

Testing authentication properly means going beyond "does the login page work" and checking rate limiting, session lifecycle, token quality, MFA robustness, and every alternate authentication pathway. The good news: most of these issues are fixable with standard patterns. Use proven libraries, enforce MFA, invalidate sessions properly, and you've closed off the majority of the attack surface.