What Is An Enumeration Attack?
An enumeration attack is a broad term for an attack that tries to uncover information by trying different inputs and seeing which are valid.
For authentication purposes an enumeration attack happens when a hacker tries different inputs to uncover information like valid usernames, emails, or passwords to help bypass authentication defenses, like your users’ login screens.
Why “help” instead of just “bypass”?
That’s because these attacks focus on gathering information. Even just discovering a valid username (and not the password to go with it) is a success, as it can lead to other attacks that break through your authentication, like password cracking.
If you don’t have the right defense mechanisms in place, enumeration attacks will find an exploit and take over your users’ accounts. But fear not! This guide will reveal seven cheat codes hackers use to exploit enumeration vulnerabilities and, more importantly, how you can counter them.
How Login Enumeration Attacks Work
When a hacker navigates to your login screen they will enter a random username and password combination. After that they will typically get one of three outcomes:
- They will get a message that the username does not exist. (Let’s them know the user doesn’t exist and they can stop wasting their time and try a different one)
- They will get a message saying the password is incorrect. (Let’s them know the password is incorrect but the username is!)
- They will successfully log in. (Well, that’s self explanatory 😂)
There are plenty of opportunities for hackers to try and exploit an authentication system for enumeration attacks. Here is a list of seven common ones that we are going over:
- Exploiting Login Error Messages 🚨
- Manipulating Password Reset Forms 🔑
- Abusing Registration Forms 👤
- Scraping API Responses 🛠️
- Timing Attacks: The Millisecond Giveaway ⏳
- Abusing Forgot Username Features 🤔
- Using Social Engineering and Data Leaks 💀
1. Exploiting Login Error Messages 🚨
When an app encounters an error, it typically generates a message to inform users or developers about what went wrong.
Descriptive error messages are crucial for debugging and user feedback. However, poorly designed messages can be exploited by hackers to gather information that helps them break into a system and steal sensitive data. To prevent this, error messages should never expose personal details like database connection strings, usernames, emails, passwords, or session tokens. Even revealing whether a username or password is correct (or incorrect) can provide attackers with valuable clues. These attacks are often automated, making them even more effective.
🚫 Don’t: “Password is incorrect.”
🔴 Why it’s bad: This confirms the username exists just the password is wrong, allowing hackers to compile a list of valid usernames and try different passwords.
✅ Do: “Username or password is incorrect.”
🟢 Why it’s better: This prevents attackers from knowing which part is wrong, reducing the risk of targeted guessing.
Additionally, error messages should avoid exposing backend technologies or software versions, as outdated or vulnerable components can become attack vectors.
Even a simple message like “This username does not exist” can be dangerous, because attackers now know not to continue testing passwords using this username.
How To Shut It Down 🚫🔒
🛑 No peeking at dev errors. Make sure production settings don’t expose technical details.
🤐 Keep error messages vague. The less info you give, the harder it is to exploit.
🚧 Handle errors carefully. Don’t let backend slip-ups reveal system secrets like database credentials or API keys.
⏳ Slow down login attempts. Bots hate waiting. Add timeouts or lockouts after too many failures.
👀 Watch for weird login spikes. If someone’s hammering your login form, they’re probably up to no good.
By following these steps, you can keep error messages useful for users while preventing hackers from exploiting them.
2. Manipulating Password Reset Forms 🔑
Password reset forms are a common target for attackers looking to gain unauthorized access to accounts. If not properly secured, they can be exploited to gather information or launch automated attacks.
A common mistake is revealing whether an email or username exists in the system. This allows attackers to compile a list of valid accounts, making brute-force or phishing attacks easier.
🚫 Don’t: “A reset link has been sent to your email.”
🔴 Why it’s bad: This confirms whether an email is registered, which hackers can use to build a list of valid accounts
✅ Do: “If this account exists, a reset link has been sent.”
🟢 Why it’s better: This response provides no indication of whether the email is valid, making it harder for attackers to enumerate accounts.
Another risk is allowing unlimited password reset attempts. Attackers can repeatedly trigger reset requests, flooding a user’s inbox or even intercepting links if additional security is lacking.
How to Shut It Down 🚫🔒
Want to keep hackers out? Here’s how to make sure your password reset form isn’t an open invitation:
🔥 Don’t spill the beans. Keep reset messages vague. No need to confirm whether an email exists.
⏳ Slow them down. Limit reset attempts and add CAPTCHAs if someone gets too click-happy.
🔗 Make reset links a ticking time bomb. Reset links that expire quickly keep attackers from sneaking in later.
🔑 Double-check who’s asking. Add extra verification, like multi-factor authentication (MFA), before letting someone reset a password.
📊 Keep an eye on things. If you see a flood of reset requests, you might have an attack in progress.
Lock it up tight, and only the right people get back in. 🚀
3. Abusing Registration Forms 👤
Registration forms may seem harmless, but they are also susceptible to exploiting. They can be a goldmine for attackers.
If your registration form reveals whether a username is taken, hackers can compile a list of valid accounts.
🚫 Don’t: “This email is already registered.”
🔴 Why it’s bad: This confirms which emails exist in your system, making it easy for attackers to compile a list of real users.
✅ Do: “If this email exists, you’ll receive a confirmation link.”
🟢 Why it’s better: This keeps hackers guessing and prevents email enumeration attacks.
How To Shut It Down 🔒
🤐 Keep error messages vague. Don’t confirm whether an email or username exists.
🤖 Use CAPTCHAs. Make bots prove they’re human before registering.
4. Scraping API Responses 🛠️
Hackers also use APIs to gather information about your users, often without even triggering the traditional security alarm bells like unusual login attempts. Here is how hackers use APIs to gather information on your users.
Status Code Enumeration
APIs often return different HTTP status codes depending on whether a request is valid or not. Hackers take advantage of this to systematically check which usernames or emails are valid.
Example trying to find usernames:
GET /api/user?email=johndoe@example.com --> 200 OK (Valid email)
GET /api/user?email=fakeuser@example.com --> 404 Not Found (Invalid email)🚫 Don’t: Return different HTTP status codes for valid vs. invalid users.
🔴 Why it’s bad: Attackers can easily figure out which usernames exist based on the response.
✅ Do: Always return the same status code (e.g., 200 OK).
🟢 Why it’s better: This prevents hackers from distinguishing between valid and invalid users.
Error Message Clues
Super descriptive error messages can give hackers hints about your authentication’s inner workings. Instead of returning generic messages, error messages often try to be helpful (which makes sense and we are often encouraged to provide helpful error messages), but this comes at the expense of giving hackers potential help too by giving specific reasons for a failure.
Examples of error messages hackers can take advantage of:
POST api/login with incorrect username --> Response: "User not found"
POST /api/login with correct username but wrong password --> Response: "Invalid password"The incorrect username allows hackers to move on, knowing that this username doesn’t exist. No need to waste further time.
The incorrect password lets hackers know the username is correct but the password isn’t. Success! Now they can try password cracking to try and get the correct combination to breach your authentication defenses.
🚫 Don’t: Include detailed error messages like “User not found.”
🔴 Why it’s bad: It confirms whether an account exists, making enumeration easier.
✅ Do: Use a generic message like “Invalid credentials.”
🟢 Why it’s better: This keeps attackers guessing without frustrating legitimate users.
Using scripts hackers can send out thousands of API requests to try and find information about your users and try to get through your defenses. In addition to potentially gathering information on your users, without the proper handling on your end, this can also overwhelm your system.
Hackers can use this data for credential stuffing (testing leaked passwords) or phishing attacks (targeting real users).
How To Shut It Down
📏 Standardize API responses. Always return the same status code and generic error messages.
🚧 Rate-limit API requests. Block or slow down repeated requests from the same IP.
📊 Monitor API traffic. A sudden surge in requests could mean someone might be scraping.
5. Timing Attacks: The Millisecond Giveaway ⏳
Sometimes all it takes is a few milliseconds for hackers to figure out if a username exists. Even if your API doesn’t return different error messages, response times from APIs can also provide hints to hackers about which usernames/emails are valid or not.
The way this works is when attackers submit different usernames to your API, they measure how long each request takes to process. Even a tiny difference in the response time can indicate if an account exists or not.
POST /api/login with a valid username --> responds in 120ms
POST /api/login with a fake username --> responds in 80msThis is because systems validate usernames first, then check passwords. If the username doesn’t exist, the request might get rejected early, leading to a faster response. Hackers can automate thousands of these requests, and analyze response times to extract valid accounts.
🚫 Don’t: Allow response times to vary based on input validity.
🔴 Why it’s bad: Even if your API returns the same error message, timing leaks can still reveal valid accounts.
✅ Do: Introduce a consistent delay for all login attempts.
🟢 Why it’s better: This prevents attackers from distinguishing between valid and invalid users.
How To Shut It Down 🔒
⏳ Equalize response times. Add a small, consistent delay (like 200ms) to every request, regardless of validity.
🚧 Implement rate limiting. Block or slow down repeated requests from the same IP to prevent attacks.
🔍 Monitor unusual login patterns. If you see a high number of failed requests with nearly identical timing differences, it could indicate a timing attack.
6. Abusing Forgot Username Features 🤔
The “Forgot Username” feature may appear harmless, but this is exactly what hackers may want you to continue believing.
If your systems confirms whether an email is registered, hackers can exploit it to gather information before going into further attacks like phishing attacks or credential stuffing attacks.
When apps allow users to request a username reminder by entering their email, the app responds differently based on whether the email is registered or not. Hackers can use this to confirm which accounts exist.
If the account exists, your users are likely to get a response like “Your username has been sent” or if it doesn’t you are likely to receive “No account found”
🚫 Don’t: Return different responses for valid vs. invalid emails.
🔴 Why it’s bad: This allows attackers to confirm whether an email is registered, making enumeration attacks easy.
✅ Do: Return a generic response like “If this email is registered, your username will be sent.”
🟢 Why it’s better: Attackers won’t know whether the email is valid.
How To Shut It Down 🔒
🛑 Use the same response for all requests. Always return a neutral message to prevent enumeration.
📩 Add a secondary verification. Instead of immediately showing the username, send a confirmation email requiring the user to verify the request.
7. Using Social Engineering & Data Leaks 💀
Hackers don’t always need to guess credentials if they can trick your users into giving them up. By combining leaked data with social engineering tactics, hackers can bypass your authentication security. As sophisticated as our technology gets, we as people are still the weakest link in cybersecurity.
Hackers exploit social engineering and data leaks by combining public data with enumeration. They scour data breach dumps, social media and other public sources to find email and usernames .They they test these against your system using enumeration techniques like login errors, password reset forms and API scraping.
An example attack could look like this:
- A hacker finds an email ([email protected]) in a leaked database.
- The hacker tries logging in using the systems error messages to confirm the account exists.
- If they are successful, they launch further attacks to get the password, like phishing attacks.
🚫 Don’t: Rely solely on passwords for security.
🔴 Why it’s bad: Even strong passwords can be stolen through phishing.
✅ Do: Enforce Multi-Factor Authentication (MFA).
🟢 Why it’s better: Even if an attacker gets a password, they need an extra authentication step to break in.
🚫 Don’t: Assume users can recognize phishing attacks on their own.
🔴 Why it’s bad: Many phishing emails look extremely convincing, tricking even tech-savvy users.
✅ Do: Educate users on phishing tactics.
🟢 Why it’s better: If users know what to look for, they’re less likely to fall for scams.
🚫 Don’t: Ignore unusual login attempts.
🔴 Why it’s bad: If an attacker logs in from an unfamiliar country or device, that’s a red flag.
✅ Do: Monitor login anomalies and trigger alerts for suspicious activity.
🟢 Why it’s better: Catching unauthorized logins early can prevent full account takeovers.
How to Shut It Down 🔒
🔐 Use MFA wherever possible. Even if a hacker steals a password, they won’t get past the second factor.
🎓 Educate users about phishing. Run awareness campaigns and train them to recognize fake emails.
🚨 Monitor login anomalies. Alert users and admins about logins from new devices, locations, or sudden spikes in failed attempts.
How SuperTokens Stops Enumeration Attacks and Protects Your Users
SuperTokens is built with security-first authentication, preventing enumeration vulnerabilities by default.
- Generic error messages: Attackers can’t tell if a username exists or not.
- Secure session management: Prevents token theft and session hijacking.
- MFA and passwordless authentication: Removes reliance on weak passwords.
- Rate limiting and bot protection: Automatically blocks suspicious login attempts.