Identification and Authentication Failures

Identification and Authentication Failures encompass vulnerabilities that allow attackers to compromise user identities, authentication mechanisms, or session management. Previously categorized as "Broken Authentication," this expanded category recognizes that failures can occur at both the identification stage (determining who someone claims to be) and the authentication stage (verifying that claim). These vulnerabilities directly undermine the application's ability to distinguish legitimate users from attackers, making them a critical security concern.

Authentication is the gateway to all other security controls. If an attacker can authenticate as another user, they inherit all of that user's permissions, bypassing access controls, data protection, and audit trails. Modern web applications face a wide range of authentication threats, from brute force and credential stuffing attacks to sophisticated session management exploits and MFA bypass techniques. The proliferation of data breaches has created massive databases of compromised credentials, making credential stuffing one of the most effective and widespread attack vectors.

Common authentication and identification failures include:

• Permitting brute force, credential stuffing, and password spraying attacks due to missing rate limiting, account lockout, or CAPTCHA
• Weak password policies that allow common passwords, short passwords, or passwords without complexity requirements
• Credential storage using weak hashing (MD5, SHA-1) or plaintext, enabling mass password recovery from database breaches
• Missing or bypassable multi-factor authentication, particularly for administrative accounts and sensitive operations
• Session management flaws: predictable session IDs, sessions that don't expire, missing invalidation on logout or password change, session fixation
• Exposing session identifiers in URLs, making them visible in browser history, referrer headers, and server logs
• Account enumeration through different error messages for valid vs. invalid usernames
• Insecure "remember me" functionality that uses predictable tokens or stores credentials client-side

Credential stuffing is the most prevalent authentication attack today. Attackers acquire leaked credential databases from previous breaches (available on dark web marketplaces and paste sites), then automate login attempts against target applications using tools like Sentry MBA, OpenBullet, or custom scripts. Because users frequently reuse passwords across services, a significant percentage of leaked credentials will work on other sites. A typical credential stuffing attack tests thousands of credential pairs per minute:

# Example credential stuffing with Python
import requests
for email, password in credential_list:
  resp = requests.post('https://target.com/api/login',
    json={'email': email, 'password': password},
    proxies={'https': next(proxy_rotation)})
  if resp.status_code == 200:
    log_successful_login(email, password)

Attackers rotate through proxy pools and distribute requests to evade IP-based rate limiting. Without robust detection mechanisms (device fingerprinting, behavioral analysis, credential breach checking), these attacks are difficult to distinguish from legitimate login attempts.

Session hijacking exploits weaknesses in how the application manages authenticated sessions. If session tokens lack sufficient entropy, attackers can predict or brute-force valid session IDs. If sessions are transmitted over unencrypted channels (missing Secure flag on cookies) or exposed in URLs, they can be intercepted through network sniffing or referrer header leakage. Session fixation attacks force a known session ID onto a victim's browser (through URL parameters, cookie injection, or cross-subdomain cookie scope) and then wait for the victim to authenticate, inheriting their authenticated session.

MFA bypass techniques target implementation weaknesses rather than the MFA concept itself. Common bypasses include: response manipulation (changing a failed MFA response from {"success": false} to {"success": true}), direct navigation to post-MFA pages by manipulating the redirect URL, exploiting missing rate limiting on OTP entry to brute-force 4-6 digit codes (only 10,000-1,000,000 possibilities), using backup codes or recovery flows that have weaker security, and SIM swapping or SS7 attacks against SMS-based MFA. Social engineering attacks that trick users into providing MFA codes through phishing proxies (using tools like Evilginx2 or Modlishka) can bypass even hardware token-based MFA.

• Mass account compromise through credential stuffing, potentially affecting a large percentage of users who reuse passwords from other breached services
• Administrative account takeover granting attackers full control over the application, including access to all user data, configuration settings, and system functions
• Identity theft and fraud when attackers assume legitimate user identities to perform financial transactions, access sensitive data, or make unauthorized changes
• Session hijacking enabling attackers to perform any action the victim is authorized to do, without knowing their credentials
• Data breaches resulting from compromised accounts, particularly when high-privilege accounts like administrators or database operators are targeted
• Compliance violations under PCI DSS (Requirement 8), HIPAA, SOC 2, and NIST 800-63 which mandate specific authentication controls
• Reputational damage and loss of user trust when account compromises are publicized, particularly if the application handles financial or healthcare data
• Legal liability for failing to implement industry-standard authentication protections, especially for applications handling sensitive personal data

1. Implement robust rate limiting and account lockout on authentication endpoints. Use progressive delays (exponential backoff) after failed attempts. Lock accounts after 5-10 failed attempts with a time-based unlock (15-30 minutes) or require CAPTCHA completion. Apply rate limiting per IP, per account, and globally to prevent distributed attacks.
2. Enforce strong password policies: minimum 12 characters, no maximum length restriction (up to a reasonable limit like 128 characters), and check against known breached password databases using the Have I Been Pwned API (k-anonymity model). Do not require arbitrary complexity rules (uppercase, special characters) that reduce usability without meaningfully improving security.
3. Implement multi-factor authentication (MFA) for all users, with strong MFA (TOTP, WebAuthn/FIDO2, hardware tokens) required for administrative accounts. Ensure MFA cannot be bypassed by direct URL access, response manipulation, or rate-limited OTP brute force. Avoid SMS-based MFA for high-security applications due to SIM swapping risks.
4. Use secure session management: generate session IDs with at least 128 bits of entropy using cryptographically secure random number generators. Set cookie attributes: Secure, HttpOnly, SameSite=Strict (or Lax), and appropriate Domain and Path scope. Invalidate sessions on logout, password change, privilege change, and after a reasonable idle timeout (15-30 minutes for sensitive applications).
5. Hash passwords using Argon2id, bcrypt (work factor 12+), or scrypt. Never store passwords in plaintext or with reversible encryption. Implement pepper (server-side secret) in addition to per-password salts for defense-in-depth against database compromise.
6. Prevent account enumeration by returning identical responses for valid and invalid identifiers across all flows: login, registration, and password reset. Use generic messages like "If an account exists with that email, you'll receive a reset link." Ensure response times are consistent to prevent timing-based enumeration.
7. Implement credential breach detection: check new passwords against known breach databases at registration and password change. Monitor for credential stuffing attacks using failed login analytics, impossible travel detection, and device fingerprinting. Notify users when their accounts show signs of compromise.
8. Implement secure "remember me" functionality using long-lived refresh tokens (not persistent sessions) that are bound to the device, stored securely, and revocable. Require re-authentication for sensitive operations (changing password, email, payment methods, or security settings) even within an active session.

Authentication testing should be comprehensive and methodical, covering all aspects of the identity lifecycle: registration, login, password reset, session management, and logout. Start by mapping all authentication-related endpoints and flows. Test the login form for credential stuffing resilience: attempt 100+ rapid login attempts with invalid credentials and observe whether rate limiting, CAPTCHA, or account lockout activates. Use Burp Suite Intruder or custom scripts to test at various speeds. Verify that rate limiting cannot be bypassed using X-Forwarded-For header manipulation, different User-Agent strings, or by distributing requests across session cookies.

Test password policy enforcement by attempting to register or change passwords using weak values: common passwords (from the RockYou top 1000 list), single-character passwords, passwords matching the username or email, and passwords known to have been breached. Verify that the password policy is enforced consistently across all endpoints that accept passwords (registration, change password, admin user creation). Test MFA implementation by attempting to: skip the MFA step by navigating directly to post-authentication URLs, brute-force OTP codes (determine if rate limiting exists on OTP verification), reuse previously valid OTP codes, and manipulate the MFA verification response.

For session management testing, use Burp Sequencer to analyze the randomness of session tokens by collecting at least 10,000 tokens and running statistical analysis. Verify that sessions are properly invalidated on logout by capturing a session cookie, logging out, and attempting to reuse the old cookie. Test that sessions are invalidated when the password is changed from another device. Check for session fixation by setting a session cookie before authentication and verifying that a new session ID is issued after successful login. Test the "remember me" function for predictability, proper scoping, and revocability. Use OWASP ZAP's authentication module to automate session management checks. For applications using JWTs, test for algorithm confusion (RS256 to HS256), the "none" algorithm bypass, token replay after logout, and claim manipulation using tools like jwt_tool.