Account Enumeration

Also Known As

TL;DR

Explanation

Account enumeration happens when an application reveals whether a username exists through different HTTP status codes, response bodies, response times, or error messages (e.g., 'This email is not registered' vs. 'Incorrect password'). Armed with a valid username list, attackers can run targeted credential-stuffing or brute-force attacks. Prevention: use generic error messages ('Invalid credentials'), ensure consistent response times with a dummy password-check for unknown users, and implement rate limiting.

Diagram

sequenceDiagram
    participant ATK as Attacker
    participant APP as Application
    ATK->>APP: POST /login user=alice@ex.com pass=wrong
    APP-->>ATK: Email not found - reveals alice does NOT exist
    ATK->>APP: POST /login user=bob@ex.com pass=wrong
    APP-->>ATK: Wrong password - reveals bob DOES exist
    Note over ATK,APP: Attacker now knows valid accounts
    Note over ATK,APP: Fix: always return same message
    ATK->>APP: POST /login user=bob@ex.com pass=wrong
    APP-->>ATK: Invalid credentials - no account info leaked

Common Misconception

Why It Matters

Common Mistakes

• Returning 'user not found' vs 'wrong password' — both messages reveal account existence.
• Different response timing for valid vs invalid usernames leaks the same information as different messages.
• Password reset forms that say 'no account for that email' rather than a generic confirmation.
• Registration forms that reveal 'username already taken' without rate-limiting or CAPTCHA.

Avoid When

• Do not use distinct error messages per failure reason on auth endpoints — merge all failures into one generic response.
• Avoid varying response timing based on whether an account exists — constant-time comparisons prevent timing oracle attacks.
• Do not expose account existence through side-channels like redirect destinations or HTTP status codes.

When To Use

• Understanding this attack is essential when designing login, registration, and password-reset flows.
• Apply enumeration defences on any endpoint where attacker knowledge of a valid account provides value.

Code Examples

// Different messages reveal whether account exists
if (!\$user) {
    return 'No account found with that email';
}
if (!password_verify(\$pw, \$user->password)) {
    return 'Incorrect password'; // confirms account exists!
}

// Same message regardless of failure reason
function login(string \$email, string \$password): ?User {
    \$user = User::where('email', \$email)->first();

    // Always run password_verify — prevents timing-based enumeration too
    \$hash  = \$user?->password ?? '\$argon2id\$v=19\$m=65536,t=4,p=1\$dummy\$dummy';
    \$valid = password_verify(\$password, \$hash);

    if (!\$user || !\$valid) {
        return null; // identical response for both failure cases
    }
    return \$user;
}

References

• ↗ https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• ↗ https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account

Tags

Related Terms