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:

enter image description here

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.


  • 1
    I find your question not very clear. Why don't you define what you mean by "login throttling" vs "temporary lockout"? Or are you looking for a definition of those terms? Please note that there is a significant difference between limiting ability for a specific username to log in (temporarily marking that user so their account cannot be logged into for the next 10 seconds, say) vs limiting ability of a specific session to log in (temporarily marking a session ID or IP address so it cannot log in as any user for the next 10 seconds).
    – D.W.
    Dec 4, 2014 at 1:01
  • 2
    And don't forget to take into account concurrent attempts to log in. Someone can open two tabs, or connect from two different IP addresses; if an attempt to log in as user U from one address fails, how do you plan to treat an attempt to log in as user U from the other address? Finally, keep in mind that these only help against targeted attacks (the attacker has a specific user whose account he wants access to) but not untargeted attacks (the attacker wants to get into any valid account, he doesn't care which).
    – D.W.
    Dec 4, 2014 at 1:02
  • By I have initially suggested that login be throttled whereby pauses are introduced between each failed login attempt do you mean HTTP throttling the response? i.e. so if there is an incorrect login, there is an artificial delay before the HTTP response is returned. If so that is an entirely different question than the one that seems to have been answered. Just a guess from me as I'm from a development background. Dec 4, 2014 at 14:35
  • By throttling i meant that the user will not be able to attempt to login again before a certain amount of time has elapsed.The rational from a UX point of view is that this will slow users down and make them think. After each failed attempt they will see a different message actively guiding them to consider a password reset. From a security point of view I am hopping that this will counter brute force attacks.Don't know if i have answered your question?
    – Okavango
    Dec 4, 2014 at 14:48
  • As AviD says, they are both the same the way you describe. Dec 4, 2014 at 15:05

5 Answers 5


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.

  • 7
    I'm going to remember that last sentence, interesting way of detecting attacks. Dec 4, 2014 at 0:46
  • This is wrong, they do not differ in those things - you should apply logging, UX, etc to both throttling AND lockout, for the simple reason that lockout IS throttling. While you might decide to implement a different UX depending on lockout time / throttle rate (e.g. 30 minutes vs 10 seconds), trying to force a difference between them is a false dichotomy.
    – AviD
    Dec 4, 2014 at 10:07
  • @AviD nobody said they were entirely different. Both are failed login attempts, and you should of course log both, but locking an account is a different conceptual event, so would have additional logging. Signifying not only did the login fail (again) but it was the 4th such successive failed attempt. Again nobody is suggesting NOT to log a failed attempt that doesn't result in a lock, in fact they are completely necessary for locking. Dec 4, 2014 at 14:13
  • Uhh @AndrewHoffman it sounds to me like you are contradicting yourself? You they're not different, but then you insist that they are "different conceptual event"; you say logging is needed for both but then elaborate that logging is not needed if it wasn't "locked".
    – AviD
    Dec 4, 2014 at 14:36
  • 1
    What I was trying to explain is that not only are these two concepts very similar, with the exception of some small details - these are both the same concept. Two ways of looking at the same thing. Account lockout is one way of implementing throttling - which is its entire purpose. So when you say they are "different conceptual event" I really don't know what you are referring to.
    – AviD
    Dec 4, 2014 at 14:38

"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.

  • The perceived difference could be in the implementation. A valid user trying to log in when the account is "locked" would receive a message saying that the their account is locked. With your first example X=10, Y=10 They would only be able to log in if they managed to successfully log in if they entered their credentials within 10 guesses after it had been unlocked again. This is a DoS against the valid user. Dec 4, 2014 at 12:11
  • However, a valid used trying to log in when the account is "throttled" (I'm assuming the dev team meant "HTTP throttled response" by this) would be able to submit their credentials at any time and the system would log them in once the artificial delay had passed, albeit with a spinning disc and possibly some sort of message explaining that they should wait a while longer. I do agree this is on the specifics of the implementation, but this will be at the forefront of a good development team's minds when discussing such issues. Dec 4, 2014 at 12:11
  • @SilverlightFox thanks, I did mention that you could choose a different implementation and UX according to whichever mental model fits you best, but at its core they are the same thing. I dont think the dev team meant "HTTP throttled response", it doesnt seem to me to be the context. I am assuming they probably meant as some of the other answers here, e.g. on the client, or some other broken model - or more likely, hadn't given thought to what this mechanism actually does (and thus see that its the same thing).
    – AviD
    Dec 4, 2014 at 12:35
  • Huh, I thought I mentioned that, I see now it was only in a comment on another answer. Oh well.
    – AviD
    Dec 4, 2014 at 12:35

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.


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.

  • This is an arbitrary distinction, there is no reason to assume that throttling would be done on the client only. For that matter, I have seen far too many (broken) implementations of lockout on the client, too...
    – AviD
    Dec 4, 2014 at 10:16
  • I was referring to the terms used in the question and said it can be done on the client, not that it must. The term "account lockout" already excludes client lockouts, the term "login throttling" does not.
    – kapex
    Dec 4, 2014 at 11:34
  • Unfortunately it doesn't exclude client lockouts, it's just that that is the completely wrong way to do it. Same thing applies to throttling (which, as I said, is the same exact thing) - throttling CAN be done on the client, but that would be the wrong way to go about it.
    – AviD
    Dec 4, 2014 at 11:50
  • 1
    Wait, maybe I got the wording wrong? By "can be based on an account" vs "can be based on a client" I didn't mean client-side. I mean like set a rate limit based on the IP address, temporarily block or show a captcha to clients that fail to often.
    – kapex
    Dec 4, 2014 at 17:43
  • 1
    Ahhh okay that is different, sorry I assumed you meant "on the client (side)". Still, throttling by IP is far from a good idea, there are too many ways it can go wrong.
    – AviD
    Dec 5, 2014 at 8:26

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).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .