Road Trip to Ruin: Navigating the Roads of User Enumeration

Hey! It’s been awhile since the last AppSec Travels blog. In this post we wanted to write about a vulnerability that is near and dear to our hearts: User Enumeration. In the world of application security, some vulnerabilities are loud and catastrophic, while others are subtle, acting as silent facilitators for more significant attacks. User enumeration is the process of determining valid user accounts, usernames, or email addresses that falls squarely into the latter category. Our vulnerability assessments show that this vulnerability remains a widespread issue. The very first vulnerability I had to assess in my young career was email enumeration. The SaaS-based application I was working with did what all SaaS-based applications do and commingled all users in the same database table. This leads to an enumeration flaw when a user would change their email address inside the application. The application would alert the user that the email was already in use. I honestly don’t remember how we fixed it, but it probably used captchas and rate limiting to mitigate the risk, and still alerted the user to the email in use (sometimes you have to meet Product in the middle). However, since then user enumeration has been part of my daily routine. Whenever we do developer training we talk about user enumeration and Seth turns to me and asks in his sultry, made-for-radio voice, “Justin, how often do you think we see user enumeration?”; my answer is:

My facial expression also matches Severus, (it’s not actually always but it might as well be). 

Checking the Map: Our Data Shows Detours Ahead

In an analysis of 82 client assessments, our reports revealed: 84.15% of applications assessed had some type of enumeration vulnerability. This means a vast majority of the applications we reviewed are giving away information to potential attackers.

With 67% of the total findings being medium severity, and an additional 3% high severity and 30% low severity, the risk is clear and present. The most common vulnerability types are found in the fundamental authentication flows: login and forgot-password endpoints.

Where the Pitfalls Are Found

User enumeration vulnerabilities are essentially information leaks that occur when an application’s response to an attacker provides a discernible difference between a valid and an invalid user input.

1. Login Endpoint Enumeration

• How it shows up: The system provides distinct server responses or different error messages for a valid account versus an invalid one. For example, the error “Invalid Password” confirms the username exists, while “Invalid Username or Password” (for an invalid username) is less revealing.
• Why: Developers often provide specific feedback for a better user experience (e.g., “we found that email, now enter your password.”) but fail to consider the security implications of this specificity.

2. Forgot-Password Endpoint Enumeration

• How it shows up: Similar to login, this endpoint often gives unique responses for an existing email address compared to a non-existing one, or provides specific error messages revealing account status.
• Why: The intent is to inform the user if they typed their email correctly, but in doing so, the application confirms which email addresses are tied to a registered account.

3. Registration Endpoint Enumeration

• How it shows up: The system returns different error messages or API responses confirming account existence when a new user attempts to register with an email that is already in use.
• Why: This is often a feature to prevent duplicate accounts, but it allows an attacker to validate a list of potential customer emails against your system.

4. Specialized Enumeration (e.g., SSN, Customer ID)

• How it shows up: This occurs when a unique identifier, like a Social Security Number (SSN) or a specific customer ID, is used in an API or form field, and the response differs based on its validity, allowing for SSN or Customer identifier exposure.
• Why: These often expose internal data structures or assumptions about data validity, allowing an attacker to probe a known sequence of identifiers to build a list of existing records.

5. Login Rate-Limit-Based Enumeration

• How it shows up: The application blocks a valid user’s account after a set number of failed login attempts, and this is communicated to the UI (e.g., “Account blocked”). However, failed login attempts on invalid accounts do not result in this block message, allowing an attacker to distinguish valid accounts from invalid ones based on which input triggers the “blocked” message.
• Why: This is a common flaw in rate-limiting or brute-force mitigation logic that is only applied to confirmed, existing accounts, thereby exposing the account’s validity status.

6. Timing Enumeration

• How it shows up: The application takes a measurably longer time to return a response for a valid account/username compared to an invalid one. This difference, often only  milliseconds, is due to the server’s internal processing (e.g., performing a password hash for a found user versus immediately failing for an unknown user).
• Why: This performance difference is a side-effect of the application’s internal processing logic, which executes more steps for a recognized account before returning an error message.

7. Enumeration as Service

• How it shows up: Unauthenticated account lookups or account validation APIs. Generally this is used during the registration process. 
• Why: Ease of use for users when creating accounts. 

Warning Signs: Enumeration as the First Stop on the Attack Roadmap

The core risk of user enumeration is that it provides the necessary groundwork for more severe attacks. An attacker who successfully enumerates valid accounts gains two critical advantages:

• Targeted Attacks: They can use the list of valid usernames/emails to perform highly effective brute-force or credential stuffing attacks. They no longer waste time trying random usernames; they can focus their efforts on guessing the password for known accounts. Beyond exposing sensitive data in enumerations one of the larger risks of exposing email addresses of users is creating an avenue of spear phishing attacks with those emails. An attacker will now have a valid email to a user of the application with this information and a little sleuthing on their part could create a phishing campaign that appears to come from the application that the enumeration occurred on. 
• Privacy Exposure: In business-to-business (B2B) or specialized applications, knowing that a specific person (identified by their email or ID) has an account with your service can be a security and privacy risk in itself.

Pothole Patrol: Security Measures for a Smooth Authentication Journey

A consistent pattern of revealing account existence through response differences is the root cause of these vulnerabilities. The fix lies in introducing uniform response handling and friction to the authentication process.

Vulnerability Type	Fix/Recommendation
Login, Forgot Password, Registration, and Change Email	Implement Generic Error Messages: The most effective fix is to use a single, vague error message for all invalid input combinations. For example, instead of “Invalid Password,” use “Invalid username or password” for both wrong username and wrong password attempts. This makes it impossible for an attacker to distinguish a valid account from an invalid one.
Registration Endpoint Enumeration	Out-of-Band Communication: Return a generic message to the UI that an email has been sent (e.g., “You will receive an email shortly”). The email can then either provide a link to complete the registration (for new users) or inform them that they already have an account for the application.
Login, Forgot Password, Change Email	Use Consistent HTTP Status Codes: Ensure your application uses the same HTTP status code (e.g., 401 Unauthorized or 400 Bad Request) regardless of whether the username exists or the password is just incorrect.
All Endpoints	Add Rate Limiting: Implement rate limiting on all authentication-related endpoints (login, forgot password, registration) to restrict the number of attempts a single IP address or user can make in a given time period. This slows down and ultimately defeats automated enumeration tools.
Brute Force Protections	Out of Band notification: Accounts can be locked out by any amount of failed login attempts. The lockout threshold should be determined by the data the account is trying to protect, an online bank account should lock at a much lower number of attempts compared to a recipe application account. Do not show signs of lockout from the application to the UI or in server responses. The application should send a single email or text to the user alerting to them that their account has been locked. It is safe to assume that valid users will use the forgot-password mechanism if they have failed several times at logging in to the application.
High-Risk Endpoints	Implement CAPTCHA: Add CAPTCHA challenges to sensitive endpoints, especially forgot password and registration forms. This provides an additional layer of friction against automated scripts.
Timing Enumeration	Normalize Response Time: Hash the incoming password first then lookup the user with the hash and username/email at the same time.
General Principle	Avoid Exposing Account Existence Information: Review all authentication-related flows to ensure no specific language or server response reveals the existence of an account to an unauthenticated user.

Off Ramp

User enumeration is everywhere and it hasn’t gotten better since I started my career in application security over a decade ago. Some of them are easy to fix and understand: just don’t tell the user that the account doesn’t exist, for example. The real hard one is registration. We are often at odds with the product team because their need for a good user experience outweighs our need to have a highly secure registration. In the end, our job is to mitigate risk the best we can and hope our applications aren’t the lowest hanging fruit. 

If you’d like to discuss the user enumeration vulnerability more or see if Redpoint Security can advise you on securing your application against user enumeration or other attacks, reach out below.