Authentication
Vulnerabilities in password-based login
User enumeration
While attempting to brute-force a login page, you should pay particular attention to any differences in:
1. Status Code
302 -> Valid Authentication
200 -> Invalid Authentication
2. Error Message
Invalid username
Incorrect username or password
incorrect password.
Example of subtle difference in error message:
Valid user -> Invalid username or password
Invalid User -> Invalid username or password.
3. Response Times
Different response times could indicate a valid response.
If you are performing user enumeration, it is recommended to increase the length of the password (e.g., testtesttesttesttesttesttest......test). This is because some applications first verify whether a username exists before checking the password. This behavior can introduce a subtle difference in response time.
4. Request Size
Pay attention to different size could indicate a valid response.
4. Account Lock out
An attacker can enumerate valid usernames by exploiting the account lockout mechanism. The application protects user accounts from brute-force attacks by locking them after a few failed login attempts.
However, this behavior can be abused to identify valid usernames:
If an account exists, multiple failed attempts will trigger a lockout, resulting in a different response or error message.
If an account does not exist, the application may return a generic error or behave differently.
By observing these differences, an attacker can systematically determine which usernames are registered in the system.
Flawed brute-force protection
Method 1#: Bypass IP-based brute-force protection
Error message such as:
You have made too many incorrect login attempts. Please try again in 30 minute(s)."
You have made too many incorrect login attempts. Please try again in 1 minute(s).
Could indicate the presence of Brute force protection. to bypass this feature add the next header:
Method 2#: Bypassing Account Lockout Mechanisms with Successful Logins
In some implementations, the system blocks an IP address after multiple failed login attempts. However, in certain cases, the failed attempt counter resets if the IP owner successfully logs in.
This flaw allows an attacker to bypass the lockout mechanism by logging into their own account every few attempts, preventing the lockout threshold from ever being reached.
To perform the brute-force attack, follow this pattern:
By interleaving failed login attempts with successful ones, the attacker can continuously attempt to brute-force credentials without triggering the lockout protection.
Method 3#: Broken brute-force protection, multiple credentials per request
In some cases, it is possible to bypass brute-force protection by submitting multiple password guesses in a single request.
If the application processes authentication requests in JSON format, you may attempt to include multiple credentials in a single request, such as:
If the server accepts this format and checks each password in the array, the attacker can effectively bypass rate limits and brute-force protections by testing multiple credentials at once.
Vulnerabilities in multi-factor authentication
Method #1: 2FA Simple Bypass
If the user is first prompted to enter a password, and then prompted to enter a verification code on a separate page, the user is effectively in a "logged in" state before they have entered the verification code. In this case, it is worth testing to see if you can directly skip to "logged-in only" pages after completing the first authentication step. Occasionally, you will find that a website doesn't actually check whether or not you completed the second step before loading the page.
If you know that the main page after login is /my-account, instead of entering the MFA code when prompted, simply try navigating directly to /my-account.
Method #2: 2FA Broken Logic
In this scenario, when a user logs in with their credentials, the application assigns a cookie that links to their account before proceeding to the second step of the login process. For example:
An attacker could log in using their own credentials and then modify the account cookie value to any arbitrary username before submitting the verification code.
Vulnerabilities in other authentication mechanisms
Resetting user passwords
The applications send a unique URL to users that takes them to a password reset page. Less secure implementations of this method use a URL with an easily guessable parameter to identify which account is being reset, for example:
In this example, an attacker could change the user parameter to refer to any username they have identified. They would then be taken straight to a page where they can potentially set a new password for this arbitrary user.
Brute-forcing a stay-logged-in cookie
A common feature in applications is the option to stay logged in even after closing the browser. To achieve this, the application generates a cookie that is either hashed or encrypted. If an attacker can easily identify the hashing algorithm used and no salt is applied, they can brute-force the cookie by simply hashing their wordlists and comparing the results.
This method can also be used to bypass login attempt limits if the application does not enforce similar restrictions on cookie-based authentication attempts.
For example, consider the following cookie:
If decoded from Base64, it follows this format:
This means the application stores authentication data in a predictable format. If no additional security measures (such as salting) are in place, an attacker could brute-force the MD5 hashed password using a dictionary attack and gain access to user accounts.
Last updated