Hub 2017.4 Help

Throttle Failed Logins

Throttling or rate limitation helps protect Hub from brute-force attacks. The Hub authentication module has settings that let you apply rate limits to logins and requests to verify credentials. Rate limits are applied per IP address. Rate limits help slow down brute-force attacks by blocking new login requests for a short time following a series of consecutive login failures, so they keep your passwords safe.

These rate limits are only applied to logins that are processed by the Hub authentication module. Logins from third-party authentication providers are subject to their own rate limitations.

How Throttling Works

The default throttling settings are tuned to discourage attackers without blocking users with valid logins. Here's a breakdown of each setting and what it does. To protect the security of your installation, the default values for these settings are undisclosed.

SettingImpact
Max sourcesThe module tracks failed authentication requests from a limited number of IP addresses. That number is large enough to block a distributed brute-force attack. We use a finite number to avoid storing all failed requests and consuming too much memory.

A counter is created for each IP address that sends an invalid request. When the authentication module has active counters equal to the maximum number of IP addresses, the collection is full. All login requests from new IP addresses are blocked until the number of active counters falls below the maximum.

Max failures per sourceEvery time the authentication module receives a failed request, an entry is added to the counter for the originating IP address. When the counter for a single IP address reaches the threshold that is set as the Max failures per source, rate limits are applied to requests that originate from this source. Subsequent requests that originate from this IP address are rejected, but continue to be added to the counter.

This means that the user who sends requests from this IP address no longer sees an error for an incorrect login or password — they are simply told to try again later. A malicious user who is trying to gain unauthorized access to the application cannot verify whether the credentials used in the rejected requests are valid or not.

Users who attempt to sign in from other IP addresses are not affected.

Cooldown rateEntries are removed from the counter for each IP address according to the cooldown rate. The cooldown rate determines how many failed requests are forgotten a set interval. As long as the counter remains above the maximum number of allowed failures, login requests are rejected from the IP address that has exceeded this threshold. When the counter falls below the maximum, login requests are processed. The user with this IP address can try to keep guessing logins and passwords.
  • If the number of consecutive invalid requests reaches the maximum, subsequent requests are rejected again.
  • When a counter reaches zero, the IP address is removed from the collection.
IP whitelistRequests from IP addresses that are included in the IP whitelist are not tracked. Use the whitelist to ensure that your administrators can still log in even when the module is tracking the maximum number of IP addresses.

How to Recover from a Brute-force Attack

Few attackers are going to have the patience to guess the conditions that trigger authentication throttling. They're much more likely to give up and move on to an easier target.

However, if an attacker managed to gain access to the application without triggering the rate limitation, you might have a problem. It doesn't necessarily mean that the throttling failed — it means that you let users create weak passwords that were too easy to guess.

If you suspect that a malicious user has gained unauthorized access:

  • Check your security logs to identify compromised accounts.
  • Browse the audit events to detect suspicious activity and identify changes that were performed by compromised users.
  • Update the settings of your Hub authentication module to enforce a stronger password policy. For more information, see Set a Password Policy.
  • Access the user profile for each compromised account and change their passwords. You can force these users to change their passwords the next time they attempt to log in.
Last modified: 21 February 2018