Bruteforce vs Denial of Service

Question

I had a problem presented today which I found quite interesting.

You have an application with a management panel. You know some of the accounts as they are standard. You want two things:

• You want to prevent bruteforce attacks
• You want to prevent a denial of service

At the moment, the user accounts were locked after 5 tries. Meaning you had to reset the password through email. This mitigates the chance of a successful bruteforce attack.

On the other hand the risk is that because there are some default accounts, that someone intentionally keeps sending bad passwords to keep disabling the accounts. This would result in a kind of denial of service for the administrative accounts.

My solution was to make the management panel only accessible through a VPN. So you would first need access to the VPN before you would be able to attempt a login into the panel.

But what if this is not an option, what can you do? (apart from continuously blocking IP's that perform bruteforce attacks)

Answer 1

For a simple solution I would say to implement an exponentially increasing delay per user per IP address.

Required delay between attempts 1 and 2 from IP a.b.c.d for user x: 1 seconds

...attempts 2 and 3: 2 seconds

...attempts 3 and 4: 4 seconds

...

...attempts 7 and 8: 1 minute 4 seconds

That way an adversary can't DoS access from an IP address or an individual user and you've pretty effectively mitigated brute force because the delay rapidly becomes unreasonable. Even if they have access to a large number of IP addresses, there likely wouldn't be enough to brute force the password keyspace, just some dictionary words.

This would allow for brute-forcing users with the same password, but if you're seeing that number of failed requests you should probably flag it anyway (in that a user with multiple bad attempts is probably not uncommon, but multiple users with bad attempts from the same IP address in rapid succession would be suspicious).

Answer 2

The correct way to do this is to use a rate limit per IP, and introduce a CAPTCHA on login for user accounts that have had a large number of invalid login attempts. The CAPTCHA doesn't need to be particularly strong, as it's mainly there to prevent non-targeted drive-by attacks. One of the benefits of this method is that it prevents both single-user many-password attacks and multi-user single-password attacks, without causing the DoS condition.

However, I would advise against indefinitely increasing timeouts. If an attacker is on the same network as the user, they may have the same publicly-facing IP address, allowing them to essentially time the user out forever by constantly sending bad login requests. This may be a rather obscure case for the large part, but consider university and school networks. Instead, the rate limiting would impose no delay on the first 2 failed attempts, 5 seconds on the 3rd attempt, 15 seconds on the 3rd, and 30s for all subsequent attempts.

One interesting case is a many-user single-password attack from a large number of source IPs, e.g. over Tor. This would likely defeat most of these mechanisms. One of the best ways I've seen to prevent such an attack scenario is to monitor the global failed login rate, and introduce site-wide rate limiting and CAPTCHAs when a large scale attack is detected.

For fixed admin accounts, it may well be worth having a separate login screen. This can be much more tightly monitored and controlled, and allows you to avoid problems with most drive-by attempts.

Another useful mechanism for increasing the cost of password guessing attempts is a client side proof-of-work function. I've seen these in use on a few sites, and I think they're pretty neat. Essentially the server sends a challenge value c, and the client must compute a salt value s such that the first n bits of sha1(c || s) are zero. The value of n can be tweaked in the same way an iteration count can be tweaked in a key-derivation algorithm. The client must compute a value of s (via brute force) that meets the criteria, and send it back to the server. The server can then trivially and inexpensively verify that s is correct. Implementation of this on the client side would normally be done in JavaScript. For legitimate users, this should pose no more than a one second delay on login, but for attackers who use their own systems to attempt thousands of passwords it increases the cost in terms of time and power consumption. Furthermore, in cases where a botnet or other malware is used as a platform for these password attempts, high CPU usage is more likely to alert the user to something being wrong with their machine.

Answer 3

For admin accounts, you were right, requiring a VPN is the right direction.
Better yet, require multi-factor authentication for admin users.

These are always good ideas.

---

That said, if for whatever reason it is not feasible, and you are stuck with regular public password logins, all is not lost.

Assuming your admin accounts are all subject to a strong password policy, direct brute force will take many, many, many, many, many tries. Attempting to brute force the password through your login form, over the internet, will take a very, very, very, very, very long time - and this will only be feasible if it is possible to run many login attempts in parallel, using many computers.
The key element here is speed.

So, the solution is to slow down the repeated login attempts, without actually stopping the real user (who is trying to login with the same account at the same time as the bruteforce is going on).
No, don't even think of trying CAPTCHA - while these do have some tiny effect, it is nowhere near enough to slow down the stream of attacks, by an order of magnitude (best bet is probably around 20% - not slow enough).

A much more effective (and simpler) solution, is rate limiting.
I.e. no more than 5 login attempts in a minute. Or 50. Or even 500.
This can also be seen as an automatically released lockout mechanism, with a very short time delay.
The math is still in your favor - you can cap it at any rate you want depending on your expected threats), and you can still leave leeway for the genuine user to login.

After several lockouts, you may want to implement longer lockouts per IP - but be careful with that approach, since IP addresses do not usually align with a specific user (either by shared IP, roaming IP, etc). So use that, if you must, but gently.

In addition, make sure you alert an administrator, after several lockouts, allowing further manual response.

Answer 4

Might I suggest a low tech solution? Don't have default accounts. Removing root and administrator on linux/windows is the first thing I do. I can't speak towards an unknown management panel, but this could be an option.

Answer 5

Continuously blocking IPs that perform bruteforce attacks is a perfectly good way to go about it. If your application logs the failed attempts into some standard location such as syslog, you can easily write a jail for fail2ban to automatically block offending IPs after a number of authentication failures.

Answer 6

Those picture questions. You know, what word is in this picture... After failed attempt 3 you have to answer what word is in the picture to push your attempt to login through. This way you don't actually lock out the account, but you prevent an automated system from continuing to function by changing the input request.

If you're worried it can be OCR'd ask a question that has multiple answers with a bubble fill in (radio button) i.e. Make it a question a human would know, but no machine would know.

Which of the following rhyme with orange?

A) Washington B) Nothing C) Sasquatch etc...

Even combine them.

Last, use multi factor authentication. I log in to my StarCraft account (geek value just went up) using an iOS app to give me a token.

Answer 7

A few things come to mind.

1) Don't use default administrative user names... ever. There is no reason for it. While security by obscurity isn't really secure, leaving your administrative usernames obvious is still making life easier for an attacker. If they don't know the admin username, they can't try to keep it locked.

2) Automatically authenticate the session from the e-mail to reset password/allow access. This allows an alternate approach to getting in without having to worry about the lockout. It is more tedious as it requires getting an e-mail to allow you in, but it works. Once in, changing the username again will effectively stop the attack.

3) IP Whitelist - this should always be an option, you could have it be whitelisted for a limited time if you wanted and could do it similarly to how #2 works, where the whitelist would be added when the e-mail link is clicked.

4) VPN as you mentioned will work, it's similar in principal to whitelisting an IP but would allow for dynamic IPs for a legit client. Depending on the context it might be kind of overkill since changing a username is still the easiest way to get around this kind of a DoS attack.

Answer 8

You don't block a user only by his username, you block him by username+IP. This way the legitimate user won't be blocked. On the other hand, dos bot will have to switch IP and eventually whole bot farm IP range will be blocked.