# Vulnerabilities in password-based login

For websites that adopt a password-based login mechanism, user either register an account or get an account from the administrator. This account is associated with a unique username and password. The fact that the user knows its password is taken as sufficient proof of the user's identity, which will compromise the website's security if an attacker is able to obtain or guess the login credentials of another user.

## Common Attacks

### Brute-force

Trial and error attack in an attempt to guess valid user credentials (username and password).&#x20;

### Username enumeration

User name enumeration is when the attacker is able to observe changes in the website's behavior in order to identify whether a given username is valid or not.

Attackers are able to generate a wordlist of usernames by trying to register a username that is already taken or entering a username with an invalid password. This two methods generate errors that will give the information that a user with that username already exists.

When attempting brute-force attacks to a login page we should pay attention to:

* **Status codes** -> If a guess returns a different status code, it is a strong indicator that the username was correct.
* **Error messages** -> The error messages can be different depending if the username or password are wrong, or both. Some times we can notice small differences in those messages that will tell us that the username is correct.
* **Response times** -> If all the requests have the same response time, one that deviate from it will suggest that something different happened, indicated that the guessed username might be correct. If the website only checks if the password is correct when the username is valid, it will increase its response time once he gets a valid username as input.

#### Labs

{% content-ref url="vulnerabilities-in-password-based-login/username-enumeration-via-different-responses" %}
[username-enumeration-via-different-responses](vulnerabilities-in-password-based-login/username-enumeration-via-different-responses)
{% endcontent-ref %}

{% content-ref url="vulnerabilities-in-password-based-login/username-enumeration-via-subtly-different-responses" %}
[username-enumeration-via-subtly-different-responses](vulnerabilities-in-password-based-login/username-enumeration-via-subtly-different-responses)
{% endcontent-ref %}

{% content-ref url="vulnerabilities-in-password-based-login/username-enumeration-via-response-timing" %}
[username-enumeration-via-response-timing](vulnerabilities-in-password-based-login/username-enumeration-via-response-timing)
{% endcontent-ref %}

### Flawed brute-force protection

There are two most common ways of preventing brute-force attacks:

* Locking the account that the remote user is trying to access if they make too many failed login attempts
* Blocking the remote user's IP address if they make too many login attempts in quick succession

To circumvent this. an attacker might notice that after too many failed login attempts his IP address is blocked, but once he login with a legit account credentials the website lets him login successfully. Meaning that merely including our own login credentials at regular intervals throughout the wordlist is enough to render this defense virtually useless.

#### Labs

{% content-ref url="vulnerabilities-in-password-based-login/broken-brute-force-protection-ip-block" %}
[broken-brute-force-protection-ip-block](vulnerabilities-in-password-based-login/broken-brute-force-protection-ip-block)
{% endcontent-ref %}

### Account locking

Websites lock out accounts if certain suspicious criteria are met, such as a set number of failed login attempts, in a way to protect it from brute-force attacks. Responses from the server indicating that an account has been locked can help an attacker to enumerate usernames, just as with normal login errors.

Account locking sometimes fails to prevent brute-force attacks in which the attacker is just trying to gain access to any random account they can.

The following methods can be used to work around this kind of protections:

1. Choose a list of candidate usernames that are likely to be valid through username enumeration or a list of common names.
2. Choose a very small shortlist of passwords that are more likely to belong to any of the users, which cannot exceed the number of logins allowed.&#x20;
3. Use a tool like Burp Intruder, try each password with each candidate usernames, attempting to brute-force every account without triggering the account lock (a single user using one of the passwords is enough to compromise the account).

Account locking also fails to prevent credential stuffing attacks. Credential stuffing involves using a massive dictionary of `username:password` pairs, composed of genuine login credentials stolen from data breaches. Since every username is only attempted once, account locking won't protect agains credential stuffing, and may result in compromising many different accounts with just a single automated attack.

#### Labs

{% content-ref url="vulnerabilities-in-password-based-login/username-enumeration-via-account-lock" %}
[username-enumeration-via-account-lock](vulnerabilities-in-password-based-login/username-enumeration-via-account-lock)
{% endcontent-ref %}

### User rate limiting

Websites can also prevent brute-force attacks through user rate limiting. User rate limiting means that making too many login requests within a short period of time causes our IP address to be blocked. Then, the IP address can only be unblocked in one of the following ways:

* After a certain period of time has passed
* By an administrator
* By the user after successfully completing a CAPTCHA

User rate limiting is less pront to username enumeration and denial of service attacks, thus sometimes preferred to account locking mechanisms. However, as seen in the previous lab, there are several ways we can manipulate our apparent IP in order to bypass the block.

We can bypass this defense if we can work out how to guess multiple passwords with a singe request, as the limit is based on the rate of HTTP requests sent from the user's IP address.

#### Labs

{% content-ref url="vulnerabilities-in-password-based-login/broken-brute-force-protection-multiple-credentials-per-request" %}
[broken-brute-force-protection-multiple-credentials-per-request](vulnerabilities-in-password-based-login/broken-brute-force-protection-multiple-credentials-per-request)
{% endcontent-ref %}
