REST Services: Limiting the concurrency of a login endpoint

Question

Scenario:

A botnet is recruited to try to authenticate against a website or service with each bot trying infrequently using a common password and a list of 'real' email addresses, avoiding the account lock-out mechanism.

Mitigation:

Add a choke in code to limit the max concurrent login requests, plus a long delay in negative response.

The choke allows n simultaneous callers, tuned to normal traffic patterns. When a caller presents invalid creds, the service imposes a 6 second wait and returns 404.

Callers queue on a busy choke, and the choke will throw a 404 if the caller is left queuing for 6s, appearing like a bad login attempt. The choke is held for the entire duration, including the 6s wait for bad creds.

The idea is that if an unusual volume of bad login attempts arrive at the service, then the system will cludge-up quickly and most requests will queue and see a 404, even for valid credentials.

Assuming an attacker figures out that this mechanism exists, I'll have introduced a vector for easily clogging the service up and denying legit users from logging-in; the rest of the service will run fine and the 6s wait does not block a thread.

That said, the load-balancer has call rate limiting so that individual callers repeatedly hitting the login service and making it cludge-up, will eventually be stopped.

The alternative is not having this mechanism at all.

It's not yet live, we're pre-launch so I have no real-world insights. Is this a smart idea or dumb?

Luke

Answer 1

It is a bit difficult to judge if your scheme is reasonable or too much because it fails to provide any information on what the application does or what the value of the resource being protected is. Your security should be matched to your risk analysis i.e. the likelihood of attackers and the consequences should an attack be successful.

From your description, my main concern would be that you have built in a facility which would assist an attacker in performing a denial of service attack on your site. This may or may not be an issue, depending on your site and how the services are used. For example, if the site is one where users first authenticate and then receive some sort of token which they use for subsequent connections and if that token has a reasonable lifetime, then potential DoS issues may not be a significant problem (assuming most users are already authenticated and are able to continue to use the service). On the other hand, if the token has a short life time and users authenticate quite frequently, then this could be a problem.

From your description, it isn't clear that this is a 'real' threat your trying to protect against or a theoretical attack i.e. an idea someone has had and has decided to protect against. Do you have any evidence or reason to believe the site is likely to be targeted by a botnet style attack as you describe? While the attack type your describe does exist, a vast number of sites/services out there never see such attacks or seldom see them. It this is the situation for your site, it is likely that all this additional complexity brings you is possible inconvenience for legit users who forget their password and added complexity in your system, which has even more potential to create problems or hide vulnerabilities. Increased complexity can easily lead to increased false positives, which may well create frustration with your users and result in lost business.

As an example, just recently I assisted a company with diagnosis of a problem they had with their web application. Users were reporting increased frustration with lost sessions and having to re-authenticate too frequently. The problem turned out to be related to a security feature built into the system.

The application used a JSON web token to manage authentication/authorisation. The user would initially connect and provide their username/password etc and get a token which they could use for subsequent connections. The token had a 24 hour lifetime. All that was fine.

For added security, the token recorded the user's IP address and on each access tot the services, after decrypting the token, the service would check that the IP address recorded in the token was the same as the IP address the connection was coming from. On the face of it, this seemed reasonable. The app was mainly used from inside the corporate network. The company had a large site.

A recent network upgrade at the company resulted in the installation of approx 3000 new wirless access points and a new configuration of the wired and wireless network so that it used 802.1x across wired and wireless networks and a move from assigning IP address based on geographical location to one based on user role. One of the advantages of the new setup is that you could move around the organisation and keep your wireless connection active. As you move between access points, you may get a new connection and that new connection may have a new IP address, but to the end user, it looks like one connection. You can probably see where the problem was.

Due tot he change in IP address, the auth token no longer passed the IP test. The problem was an assumption that the user would retain the same IP address the the lifetime of their connection. However, there was also another more subtle issue. As this application is used on an internal network, which is fairly well locked down with quite a reasonable level of security, the IP check was unlikely to be actually improving security at all. The idea of the IP check was to add additional protection against session hijacking by someone who was able to steal the users token. Although this can be a real risk in some environments, in this specific environment, this was a low risk and the protection was not of any real benefit. Worse still, the data which could be accessed by the application had low value - it was information useful to staff, but was not particularly sensitive and the consequences for unauthorised access were low. This was an example of a security measure being implemented which was based on a theoretical threat rather than a real threat in the environment.

The point is, you need to assess whether your control is really addressing an actual threat or whether it might be a reasonable idea which isn't of any real benefit to your environment and could potentially have a negative impact on legit users. Is the type of attack you describe and are protecting against a real threat in your environment? What would be the consequence if that type of attack succeeded? Will the potential impact on legit users be acceptable to the business? If you enforce strong passwords and use good hashing techniques, how likely is a brute force attack likely to work anyway? I suspect that your measures may be excessive and possibly not providing any real benefit, but that depends on the application.

Answer 2

Even if users have really bad passwords (and you can mitigate that), a brute force attempt is going to require a lot of requests in order to have a good chance of being successful. If this attacker is willing to wait a really long time or maybe is attacking lots of websites, a reasonable password reset period should make it really unlikely they will stumble onto a working login.

So really the main way to prevent brute force attacks is to slow them down. In this case the attack is so slow that it is infeasible with good password rules so I'm not sure you really need to defend against it.

On a side note, I think 404 is not the right code. A 503 would be probably be more appropriate. Another option is to implement a delay on login attempts that doubles on every attempt for a user or from an IP (spoofing could defeat this.) For example, you might implement a 2 second delay after one bad attempt and after a few tries, they are SOL. Another thing is that if you see requests for lots of different IDs coming from the same client, you should probably stop servicing the requests entirely. Again spoofing could get around this.