Brute Force Protection

What is brute force

Brute-force attacks on web applications are a serious problem, especially for larger websites with many users. An attacker tries to compromise a user account either with random username and password combinations or with a so-called wordlist containing several typical usernames and several typical passwords such as admin and 1234. These lists are tried in rapid succession, and the server's response reveals whether the login was successful or not. In theory you have to assume that hypothetically any password can be cracked with brute force. The question is, however, in what time the password can be guessed. If an attack takes 20 minutes, that's acceptable for an attacker; at 500 years it looks different. So an effective way to prevent brute-force attacks is to make the time needed for a successful run as long as possible. In general it is therefore always advisable not to tell the user logging in whether the username exists. This increases the duration of a successful attack exorbitantly, because besides the password the attacker also has to guess a valid username. That makes less sense on social platforms, where every user can see the other users' usernames. An attacker would simply create a valid account and thereby obtain the other users' usernames (a possible protection mechanism is described below). Furthermore, it's generally a good approach not to signal the login result via HTTP status codes. A 403 code is easy for an attacker to intercept, and they quickly learn whether the login succeeded without having to additionally parse the website to get the login status, which means extra time gained for us.

Time span

At https://tmedweb.tulane.edu/content_open/bfcalc.php there is an interesting calculator that can work out how long a brute-force attack takes and how many combinations are possible. A password with 5 uppercase letters, two lowercase letters and two digits gives me the following result there: Your password is 9 characters long and has 803,181,017,600 combinations. It takes 15.58 hours or 0.65 days to crack your password on computer that trys 25,769,803,776 passwords per hour. This is based on a typical PC processor in 2007 and that the processor is under 10% load. 15.58 hours is relatively little and probably won't deter an attacker who has the program running on their machine. So the goal must be to extend the time span so that brute-forcing the password no longer seems worthwhile, while at the same time the user experiences as few restrictions as possible.

How to protect

Captcha

Captchas are a common approach to protect against brute-force attacks. After a certain number of unsuccessful logins, the user is shown a captcha they must additionally solve to initiate another login attempt. The advantage is that the user isn't locked out and can still log in; they do have to solve a captcha, though, which is problematic for accessibility reasons. It can also put off many users to have to enter a captcha that is sometimes not easy to read (which is the whole point).

Secret username

A "secret username" (no idea whether the term officially exists) means that the username visible on a social platform is not also the username used to log in. Alternatively, a user ID or (somewhat more convenient) the email address could be expected. This means that if I'm signed up on a social network with the username David and the email address "fancymail@d3vdav3.de", other users only see my username (David), but logging in is only possible with my email address "fancymail@d3vdav3.de". That way an attacker has to guess both the username and the password, which significantly increases the time needed for a successful attack.

Account lockout

A lockout is one of the harsh ways to protect an account against brute-force attacks. After a certain number of failed login attempts, the account is locked for a certain time. An attacker who has to wait 30 seconds after 5 attempts needs a significantly longer time to guess a password and will look for an easier target. The downside, however, is that this makes a relatively simple DoS attack possible. An attacker who knows the username can simply start several wrong login attempts at 30-second intervals and thereby deny the legitimate user a login. The legitimate user will also be annoyed if they really did forget their password and have to wait 30 seconds before another attempt is possible.

Email verification

A relatively easy and efficient option is to unlock further login attempts by email. After a certain number of wrong login attempts, the user receives an email with a link that has to be clicked to unlock the account again. This makes a new attempt possible fairly quickly, the user doesn't have to wait, and in the event of a brute-force attempt also learns that several logins failed, and can then change their password to a stronger one if necessary.

Mouse movement

Intercepting mouse movements works, but is relatively ineffective. To navigate the page the user has to move their mouse, be it to reach the input field or to click the login button. A user who performs no mouse movement at all may be a bot and could then be forced to enter a captcha. The downside is accessibility again: navigating the page is possible via the TAB key, for example, which doesn't trigger any mouse movement and would wrongly identify the user as a bot. So it would also make sense to check keyboard input. However, Chromium, for example, also triggers the keypress event, so the protection falls flat. In addition, a professional attacker won't go through the form but will send requests directly to the login script via POST request. So this protection falls flat again.

Two-factor

An additional, effective approach is using a one-time/time-based token based on two-factor authentication. The user gets, for example, an 8-digit key that changes and is regenerated after a certain time. The keys are generated on both the client and the server side using the same seed, so the server can recompute and validate the entered key. The advantage is that the key changes after, say, 30 seconds, which makes a brute-force attack harder.

Login speed

Measuring the login speed is also a way to prevent brute-force attacks. The server measures the time a user needs to start another login attempt. Assuming the legitimate user types a different password before logging in again, it takes at least a second before another login attempt can take place. A client that starts several login attempts per second can only be controlled programmatically and can therefore be regarded as a bot. So it would make sense, when there are several login attempts within a short time, to enable a captcha for additional validation, inform the user, or lock the account for a certain time.

Delay in the login process

One last option is a delay in the login process. The user does enter their credentials, but the server waits a few seconds before the login is executed. A progress bar can be shown to the user so that it looks as if the server is still processing the request. This delays every single login by a few seconds, which makes a successful brute-force attack harder.

Result

Absolute protection against brute-force attacks is not possible. It can, however, be detected and, if necessary, delayed so that the time until success is so long that it is uneconomical to actually run the attack. It's best to combine several of the methods mentioned here, always weighing usability against security.