Caveats: The following analysis is based entirely on a brute force attack. Hackers cannot extrapolate information from this document to help them learn user passwords.
iBeta does automated testing of the security of websites, especially for things like cross-site scripting (CSS), and cross-site request forgery (XSRF). However, our automated tool occasionally finds other problems not strictly related to those and not strictly in the OWASP Top Ten.
One of these has to do with the “Login page password guessing attack” that is in the module, Html_Authentication_Audit.script. This script is truly a brute force attack against a login page and does not assume that the hacker knows the username of an authentic user of the website. Therefore, even if you lock a username in your database, this particular script has most likely chosen a username or usernames that are not in your database.
Lockout Known Usernames After Failed Brute Force Attack
First, consider the case that your website locks out known user accounts after some number of failed password attempts. This refers to real usernames that are already stored in the database. After some failed logins, your website locks that user out.
Let us assume the following
- Your login page is using TLS or an acceptable variant. Therefore, if your users are logging in from an unprotected wireless internet café, your login page request is not broadcasting their username and password to the entire restaurant.
- After a specific number of failed password attempts, you lock usernames that you know, at least for a while.
Let there be a hacker! I hereby name my hacker, Hackster.
The first thing Hackster does is attack the ‘forgot password’ page and see if there is a different response for ‘I cannot find that email address in my list of accounts’ and ‘Hello dude. We sent you a new password!’ If Hackster gets the latter, then he no longer needs to brute force the username and instead is going to brute force the ‘forgot password’ page until he has a list of usernames. Suppose Hackster tried that and found out the ‘forgot password’ page was perfect.
Hackster tries usernames and passwords randomly hoping that the combination will hit before the known username lockout hits. Alternatively, Hackster attempts the same random username with random passwords. What are the odds Hackster succeeds?
How to Thwart a Brute Force Attack
Suppose your password policy is weak. You allow eight-character passwords but no other requirements. Hackster has a 50:50 chance of guessing the password after trying 267 passwords. Hackster is no fool, and can easily afford to rent 1000 zombies to attack your website. Supposing it takes 1/5 second to get a response, Hackster will have tried all of those 8,000 million combinations in 18.6 days. Hackster won in less than a month.
Therefore, if the username has an account, it might make sense to lock that account after, say, ten bad password attempts. Across his 1000 zombies, Hackster will try a new username on average every couple of seconds. Hackster may not know that a lockout will occur at the beginning, but eventually, he’ll learn that some usernames are locked after ten bad passwords, while others are not. Hackster concludes that the locked usernames belong to real users.
If a username does not belong to an account, Hackster will stop trying passwords after ten or 11 eronious passwords. Hackster is rolling over to a new username every two seconds on average, whether he hit a real username or not. He hopes that one of his combinations will hit.
Hackster tries username and password pairs bringing the likelihood that he finds a match to 2615. If we multiply his 18.6 days by 208 thousand-million, we conclude that it will take 3.9 million-million days to find a matching pair. Theoretically, Smart Hackster has done the math and gives up on his brute force attack.
Hackster likely considered hitting the site with the 11th password attempt. If he does, then he knows whether the account was real or not, but he has also generated a help-desk call from the actual user every 18-36 days. In the latter case, Hackster has a list of real usernames, and can go back after a while and try another ten passwords.
(Note that there is a clue to your Incident Response Team there. If the user does not call in soon after being locked out, then there is likely an incident in progress or Hackster is also employing social-hacking techniques—those beyond the scope of a brute force attack).
Dumb Hackster, however, is generating a help-desk call every 18 days because dumb Hackster forgot to do the math.
Because of the lockout policy on real accounts, the website has a reasonable chance of withstanding a brute force attack even with a rather poor password policy. We assumed that the round-trip time was 1/5 second. Even if the round-trip time is another 1/5 or 1/10 of that time the brute-force attempt does not better. However, the help desk call frequency increases by roughly the same factor. Therefore, some attacks could lockout a user every few days.
The previous analysis assumed usernames were relatively simple. Usernames are often case-insensitive, but applying policies to username lengths is not a common practice. Therefore, the username factor of 268 might be as small as 264 or maybe even 263. If Hackster can target the 3-6 range length of usernames, then Hackster could be generating 264 times as many lockouts as described above. Instead of one every few days or few weeks, Hackster is making 25,000 a day! It probably depends on how many short usernames there are. Hackster might run out of all of them in a few days or weeks. In the meantime, your help desk is swamped!
If your website has a policy against short usernames or requires full email addresses, then a lockout policy on an existing username is quite successful at thwarting a brute force attack even if the login page simply ignores non-existing usernames. However, as username-complexity decreases, the number of locked out accounts will increase during an attack. This is not only concerning but also an indication of an ongoing attack.
If your website is using a lockout-mechanism to mitigate brute-force attacks of the password of known users, then unless the site also locks ut usernames not in your database in the same way, then your website is leaking information about the usernames to the hacker.
Mitigating a Brute Force Attack Without Lock-Out
Suppose that you have no lockout on accounts. Is there a way to deal with brute force attacks without a lockout?
As described above, depending on the turnaround to your site, a weak password policy can result in Hackster breaking in as little as 18 days if Hackster already knows the username of the account.
First, we consider hardening the password policy. Suppose you have a password policy requiring 12 mixed-case characters that must include both letters and numbers. Hackster has a 50:50 chance of getting in within 6211 tries. That comes out to about 52 million-million-million attempts.
Suppose we penalize a wrong answer with a time-out. Hackster won’t wait for a response unless every response (good or bad) takes the same amount of time. Now, suppose our website has built-in a login delay of 2 seconds with a standard deviation of a half-second. In other words, 90% of the time a user is waiting for at least a second to log in, and only 10% are waiting longer than 3 seconds (you might even truncate the distribution around those 10%-90% marks, or use a constant delay).
Hackster’s machines have to wait 2.5 seconds or longer to be more than 70% sure that the login was unsuccessful. The worst-case suggests that Hackster picks two seconds. Let us give Hackster a million threads or a million zombies or combination thereof. Since Hackster has to wait at least two seconds before moving his thread on to the next try, his thread/machine will pause. With the bad password, Hackster is still going to win in 186 days. With that stronger password, Hackster takes over 3 million years to do the same thing!
A reasonably strong password policy combined with a login delay of a few seconds can mitigate a brute force attack. There would be no leaked information regarding the validity of a username.
For purists, the Gaussian distribution of delay times is better. This is because your internal algorithms may take slightly longer one way or the other. The Gaussian delay tends to hide that time difference a bit better than would a constant time delay. Beyond that, you should monitor your logs. If you are under attack, determine if you should block IP addresses.
Conclusions
- A website with a strong password policy that pauses a second or two before responding to a login attempt (successful or not) has a low probability of brute-force attack.
- If your website has a lockout policy for known users after some number of sequential login failures, then a brute-force attack has a low probability of success. However, as username complexity decreases, the number of help desk requests to reset accounts increases and could become overwhelming.
- If your website has a lockout policy for know users, then unless the login page responds the same way every time, your website leaks usernames.
- The lockout did hurt Hackster. After two failed passwords, he moves to the next username. However, your phones are ringing and users are inconvenienced. In this case, we recomment a secondary failed Xth-attempt login page. These pages often ask security questions or employ CAPTCHAs.
Below is a summary of solutions to brute force attacks as outlined by The Open Web Application Security Project (OWASP).
