Understanding how to prevent rapid-fire login attempts

Question

I'm having problems to fully understand how to prevent rapid-fire login attempts. My questions basically come from the The definitive guide to form-based website authentication.

The final recommendation is setting a login throttling, setting a time delay between failed attempts. Something as:

• 1 failed attempt = 5 sec delay
• 2 failed attempts = 15 sec delay
• 3+ failed attempts = 45 sec delay

A few questions that easily come to mind are:

• If we're trying to protect our system from brute-force or dictionary attacks, how is it that the delays are so restrictive?. One of the examples shows an increase of 2**2 per invalid attempt. Wouldn't a fairly minor amount of time discourage already an automated attacker?.

• In this protection scheme, what would be the client? How would it be identified?. Are we talking about an IP+account or just account?. If we are talking about just an account without taking into account the IP, isn't that likely to bother legitimate users trying to access their account?.

• I have never seen any reading material talking about humans trying to access accounts?. I understand that this case would be highly unlikely (more if we assume password policies in place) but, what if an attacker has built a list of likely passwords via some method (social engineering). Shouldn't that be protected too?. Because in that case, and being the client identified by IP+account, being very restrictive would make a lot of sense, trying to block the IP that he is using.

• How does throttling failed logins make a real difference between just simple throttling?. With simple throttling, I mean a throttle over the 'login' endpoint that controls the number of times that you try to log-in, but without taking into account if these attempts were successful or not.

Assuming this previous definition for what I meant with a simple throttle, let's assume that I am controlling the number of times that you can call the login endpoint for one account given a span of time:

• For each account, the login endpoint can be called 3 times each minute.

Would that be enough to stop a brute force attack?. Does adding this delay mentioned before when the attempt is invalid yield better results?.

I would be super grateful if anyone could shed some light here.

Answer 1

The main idea here is to quickly slow down the window for brute-forcing an attack. You normally implement this like:

• Track on an account base. (so each account has its own wait time)
• Increase the wait time exponentially.
• Have an reset mechanism for the password and or wait time through some person (Admin / service desk / etc.)

The main difference between normal throttling and the login throttle is the wait time mechanism. the exponential factor means that you quickly have to wait for more than a day per password entry (effectively blocking that account), making detection of abuse much more likely, and normal throtteling you count connections / throughput per time, and have a stable amount of allowed actions in each slot. (so its a constant rate of attempts instead of a quickly diminishing amount).

Answer 2

If the attacker is automated, then they are ok with waiting. They might let their tool run for a long time, if you let them. So, they will not get 'discouraged' easily (that's what tools are for).

Locking accounts does have a user experience impact, and each site needs to run that risk analysis. How you define the 'client' is up to your specific scenario.

Answer 3

A 'smart' attacker does not attack a single account, but tries common passwords for a wide range of user accounts.

So, if you want to defend against a rapid-fire-login-attempt attack, increasing the delay for a single account does little to protect the system as a whole.

I suggest keeping a running average of failed login attempts for the system, within a certain time limit (5 minutes for example). If the number of failed login attempts for the system start to spike, compared to the running average, you delay the login attempt feedback for all login attempts system wide.

The weight of the delay can be tuned to match the difference between the running average and the measured spike.

Once a delay has been triggered, the running average can no longer be trusted, because it is now (potentially) influenced by the attacker. So you need to come up with some other method to decide when to decrease or stop the delay in login attempt feedback.

Answer 4

You have to consider the intents of the unauthorized access. For someone, it could be to gain access to the account in order to obtain the information within. For someone else, it could be to deny the rightful owner access and use of the account. For yet another person, it could be to initiate an effective denial of service attack on a service that would otherwise shut down the packet storm or LOIC attack upstream.

IT security is not only about denying bad actors access to information, but about ensuring the authorized users have reliable and dependable access to their information.

For want of a nail... all was lost.