Best practice in web application security authentication to avoid bruteforce attack

Question

I want to cover the possible cases of attacking. My application already has captcha and two-factor authentication, but how can I avoid a tiny attack without annoying my users? The possible cases that I'm thinking to cover are:

1. Show captcha after 3 failed login attempts based on Session, but the problem is that some related articles said it should not be based on ASP.NET session as it somehow could be cleared.

2. Showing the two factor authentication after the captcha, but should I also show the captcha based on the failed count from the previous step? Or I should count from the beginning?

3. Also I'm thinking of blocking the user's IP for a certain period but that might affect other users working from same IP! What if the hacker has a tool for changing the IP periodically?

Could you please advise me, with references if it is possible, what is the best way to cover these security issues?

Answer 1

A relatively user-friendly way of mitigating brute-force attacks is delaying the minimum time between attempts. The first time your user enters wrong credentials, you let him wait 1 second before he can try again. The second time, you let him wait 2 seconds. The 3rd time, you make him wait 4 seconds. 4th time, 8 seconds, and so on. You also base this on the username that is used to authenticate, not any IP addresses. If there hasn't been an attempt in the past 5 minutes (or if the user authenticated successfully), you reset the counter.

The result is that a user that makes a typo in their password isn't affected the first few times, but any brute forcers will very quickly reach a point where brute-forcing is effectively not viable anymore.

---

Aside from preventing your web application against brute-force attacks, you should also ensure standard password protection practices like hashing & salting (preferably with PBKDF2 or bcrypt), secure password resetting, and mitigation against username enumeration. But I assume that, since you post on here, you already know that.

Answer 2

A good compromise between user experience and security would be to have IP-based captchas that trigger after a few failed logins from a particular IP, regardless of username.

• This approach isn't vulnerable to DoS attacks against a single user by bruteforcing his account until the backoff time reaches several hours/days and prevents the legitimate owner of the account from logging in.

• The number of people stuck behind a NAT isn't that high, and it's better to slightly degrade their experience with a captcha rather than prioviding attackers with the ability to completely DoS an account and lock out their legitimate owners.

• It depends on what your app is for and how long the session lifetime is, but if it's something like Stack Exchange then people usually don't log in and out frequently.

As for your concerns about using sessions to track incorrect logins, you are right, that's pointless since it'll work for legitimate users, but an attacker won't even bother storing the session cookies which means on each try he'll get a new session and new login attempts without captcha.

For the IP changing, yes that's a bit of an issue, but an IP is still a cost to the attacker, eventually he'll run out of proxies and/or compromised machines in his botnet, and he will have to buy more. You should also always require a captcha if the IP is in an open proxy database (search for one on Google) or in the list of Tor exit nodes; that way an attacker won't be able to use these "free" solutions and will have to rent a botnet or some "premium" proxies that aren't yet in the blacklists.

Answer 3

I've been doing some research on mitigating brute force attacks and came across this post. I recently implemented the following approach:

In a 24 hour period: On 20 or more failed authentication attempts for a single IP address we require captcha for each subsequent attempt. At 100 failed attempts, we blackhole requests, but give no indication that the request was blackholed, we just keep returning the standard error message.

For us this is reasonable as we are not worried about large amounts of people logging in from the same IP and we believe our thresholds are high enough to where a normal user would not be affected. Its trivial to send an alert at 100 failures or if a username appears across multiple IP addresses.

We log everything in a database. We do concede that a botnet could use a large swath of IPs, however we log the username that an IP failed to authenticate with. This table is generally checked once per day so the potentially exists for us to identify a large scale brute force attack targeting a single user.

We also recently enhanced our password requirements to increase character length and complexity as well as not allowing passwords that are in various password dictionaries. Our login page is no-indexed in Google (not in robots.txt, use the meta robots tag as attackers can check your robots.txt for interesting pages). Finally, administrator accounts require two factor authentication.

Still, we accept the risk that a brute force hack is possible.