What is the difference between login throttling and temporary account lockout?

Question

I am currently working on the redesign of a login page. I have initially suggested that login be throttled whereby pauses (incremental - in number of seconds) are introduced between each failed login attempt. The idea is that this will allow us to avoid locking the account and give users time to think about reseting their password and also counter any brute force attacks.

The development team suggested that login throttling will not help in preventing brute force attacks but a temporary lockout will. The temporary lockout works in the same way except that pauses introduced are (incremental - in number of mins and hours) so I am a bit confused...below is an example of how IBM QuickFile allows login to be configured:

So I have a number of questions:

1. Is a temporary lockout just another term for login throttling?

2. What is the difference between login throttling and temporary lockout? Are they the same but use different configuration parameters. for example 3-6-12 seconds vs 5 -10 - 20 mins ?

3. What are the interaction design implications that I need to consider when adopting a temporary lockout mechanism? Can I let the user know when they will be able to try again? Perhaps using some form of visual indicator?

4. What are the most adapted time-frames for pauses between failed login attempts that will not frustrate the end user? This post on stakoverflow seems to suggest seconds rather than mins

5. What impact does this have on Denial of Service?

Update: Clarifications

A bit more to clarify! when a Login fails the "try again" button is disabled a for a duration of 3 sec after which it is enabled.The user attempts to login again and fails, the "try again" button becomes inactive for 6 sec.

The process is repeated for 5 consecutive attempts and error messages direct users to reset their password.At the 5th attempt users are presented with a password reset screen.

On the other hand users could attempt to login and have a specified number of attempts after which the account is "locked" for a period of time, say 5 mins this increases to 10 mins after another set of attempts.

Thanks

Answer 1

A) Yep you got it. Same in that they both result from a failed login attempt(s), though they differ in things like logging, the resulting UX implementation, and when one is used.

If a user is temporarily locked out, this is email-worthy. You should send an email or text-message to them notifying them that enough failed attempts were made to warrant a temporary lockout. This is an opportunity to empower the user to intervene in the event that it isn't them attempting to log in.

Alternatively you could use just a lockout timer in minutes, but requiring action from the user to unlock the account would be more ideal.

Throttling is more for pacing. "hold your horses, take a breath" and can be done without even informing the user. A simple UI spinner element can be used to prevent the user from accidental double-form-submits and prevent rapid attempts over the span of seconds as opposed to minutes or hours.

This can also be used as an opportunity to detect bruteforce attempts if the attacker isn't going through your UI. If 3 attempts are made per second but your UI only allows 1 attempt every 3 seconds, something is amiss.

Answer 2

"Throttling" and "temporary lockout" are exactly the same thing.

It is likely, however, that your dev team misunderstood the concepts, and assumed you meant "throttling" like most of the other answers here did (with the exception of @R15, though that is less an answer and more of important considerations).

The important point that they are missing is simply this:

The entire Raison d'être of temporary lockout IS login throttling.

The account lockout is not a punishment for the user, nor does it automatically grant the account Magik Powers of Immunity from all attacks while it is locked.

The reason the temporary lockout works, is that it is effectively setting a minimum amount of time to do X number of login attempts.
In other words, a maximum number of login attempts within Y period of time.

---

Let's give an example:

With no brute-force protection, let's say an attacker can attempt 1000 passwords / second. According to this classic XKCD, most "complex" passwords would have up to 28 bits of entropy. At 1000 guesses/second, that would take approximately 3 days to brute force.

Now, let's assume you have brute force protection in place (throttling / account lockout) : After X passwords, lock the account for Y amount of time. Or phrased as throttling: Allow only X passwords every Y amount of time.
Clearly these are the same.... regardless of whether Y is 30 seconds or 30 minutes. And they both would work.

But lets have a play....

• To make it easy, we'll set the above X=10 (allowed wrong passwords), Y=10 minutes (lockout time). At that rate (it's actually 1 guess per minute, on average, just to make things easy) - it will take just over 500 years to guess (on average).
• Okay, let's lower the parameters... X=5 guesses, Y=30 seconds. Same password would take just over 50 years (since, on average, your throttle rate is 10 guesses per minute).
• Or, as you seem to have intended, X=1 guess per every Y=10 seconds (?): with an average of 6 guesses per minute, it would take around 85 years to brute force the password...

Of course you can tune those parameters as makes sense for your system, and especially, as @R15 said earlier, this should be in relation to the strength of your users' passwords.
However, whether you consider this to be "account lockout" or "account throttling" is the same exact thing, since the first is merely a simple implementation to achieve the second.

Answer 3

Something else to consider is that the average permissible attempt rate (imposed by either throttling or lockout) should in theory be tied back to the effective cover time of the users' passwords.

That is the throttling/lockout should be sufficient to prevent a brute-force attack via the web interface from being successful before the user next changes their password.

Or put another way the decision about times is related to your password complexity and change frequency.

Obviously though if you are auditing the logs you should be able to identify slow attacks against specific accounts and do something about it before there is a likelihood of a successful password guess.

Answer 4

The main difference is that an "account lockout" is based on user accounts and throttling login attempts can also be done by limiting attempts per client.

Throttling login attempts per client helps for example if a single malicious client does not target a specific account but tries a different account name on every attempt (or until the account is locked).

If you throttle login attempts per account, then it is essentially the same as a temporary lockout.

Answer 5

Throttling is used when lockout is not an option. This particularly happens when under an imperative need to avoid involving support operations (new startups with high user count), giving security more weight than business continuity, compliance or safety reasons (the lockout may endanger someone's safety).