In Password-Based Logins

If a website that uses a password based login process then the users either register for an account themselves or they are given by the admin, both the username and password are unique.

Bruteforce attacks

These attacks are typically automated using wordlists of usernames and passwords. There are n number of tools to automate this process, attacker to make vast numbers of login attempts at high speed by increasing threads.

Website's auth methods can be highly vulnerable if they do not implement proper brute-force protection.

Username Enumeration

Usernames can be easily guessed or spotted in the website itself or even by doing a little of OSINT on thier social media accounts, emails etc.

Obviously, the high privileged user can only be admin or administrator.

For example, when you enter a valid username but an incorrect password, or on registration forms when you enter a username that is already taken, this reduces the time of an attacker to bruteforce login.

Password Enumeration

Passwords can also be bruteforced, with the difficulty varying based on the strength and length of the password. Many websites have some form of password policy such as :

A minimum number of characters
A mixture of lower and uppercase letters
At least one special character

Computer's can crack high-entropy passwords but the only disadvantage is it takes years !, and moreover humans create a strong password at the same time they'll have to remember it right?

So this becomes a weakness and attackers can easily generate passwords according to thier pattern, For example : If mypassword is not allowed, users may try something like Mypassword1! or Myp4$$w0rd

Key Points to Remember

Status Codes:

The HTTP status code is likely to be the same for all the guesses because most of them will be wrong, but if it returns a different status code then it means the username was correct and it exists.

Error Messages:

The returned error message is different depending on whether both the username and password are incorrect or only the password was incorrect, this gives an idea for the attacker to guess where he went wrong while bruteforcing.

Response time:

If the requests were handled with a similar response time, any that differ from this, suggest that something different was happening behind the scenes. This is another indication that the guessed username might be correct.

First Exercise

Just use the PortSwigger's default username and password list and bruteforce it via the Intruder tab.

First try the username using the Sniper attack and then the password.

Second Exercise

Using the Grep Extract feature to pick out the odd one, firstly fetch the response and select the Invalid username or password and now we are set.

While enumerating the user we get to see an extra p tag <p> which makes it obvious that this username is a valid one

While bruteforcing the password, it straight away gives us the valid one with a low length.

=> Keep an eye on the Status code !

Third Exercise

This lab challenge is actually difficult when compared to other's we've done

The approach to this lab would be asusal but the thing to notice is we do not get any difference in the status code not the length, which makes every tester halt for a minute.

So this lab tells us how to go on enumerating the username with some time delays

When we send the POST /login request to the repeater, attempt to increase the length of the password to some 100 characters and notice something different in the response

This confirms that the password parameter gives us a time delay when we increase the number of characters.

The one more drawback of this lab is that the backend blocks our IP, after we hit our rate limit

Which means, some websites have some certain kind of rate limits on the login page functionality, if we hit the rate limit it asks us to wait for an hour or less to login again, to bypass this we can use x-forwarded-for: 0 query in the request body and iterate it via the Intruder

Meanwhile we can set the username parameter to iterate via the portswigger's username list and password remains the same(100 characters or above)

When the attack is finished, we see there's no difference in the length and status parameter, click on the columns above and select response received and response completed tabs

These two tabs will be displayed now, click on the response received tab and notice that a certain username's time is delayed drastically, so this confirms that is our username.

So now we've found our username, bruteforcing the password isn't a big deal. It's the usual way and now we'll notice a particular request will return a 302 response code which is (Found)

Flawed brute-force protection

PreviousOAuth Attacks NextXSS

Last updated 1 year ago