We are implementing a temporary account lockout after throttling login attempts and actively directing users to reset their password. Users can still go through the reset journey even during temporary lockout.

The rationale being that instead of completely locking the account after many failed login attempts, we could lock the account temporarily to encourage users to reset their password and avoid unessessary calls to customer service.

So my question refers specifically to the time frame for temporary lockout.

Are we dealing with minuets or hours? What other considerations should I take into account to help users before making a viable suggestion? For example as this is an enterprise

Update: So far what I have suggested was as follows: 5 login attempts > temporary lockout for 15 min > next 5 login attempts 30min etc. The idea here was also to encourage users to think about resting their password particularly after having expired 5 login attempts.

Some context:

This is for a software as a service web app where we do hold sensitive data and clients have their own internal security policies that we need to abide by. so really its not worth the fight. So the approach i am trying to take here is: What we can't control we can manage, hence my question.

  • 6
    as with all such questions like this I think you should be asking at the security se. From a pure UX POV any lock out is of course bad and the less the better. Feb 26, 2015 at 13:24
  • 1
    Okavango so what do you hope to achieve by introducing a lock out? If it is security based then @theotherone is right. Any lockout is horrible UX. Use an other method to get around the problem/avoid it in the first place.
    – tim.baker
    Feb 26, 2015 at 13:28
  • 1
    this Security.se question might be a decent starting point security.stackexchange.com/questions/24287/…
    – Fractional
    Feb 26, 2015 at 14:31
  • 2
    I prefer 'lock the account after x attempts, until unlocked via email' - don't use a time limit at all
    – Jon Story
    Feb 26, 2015 at 15:04
  • 1
    According to the math (and this is a Sec.SE question...), it is enough to set a few seconds delay as lockout, since all the math needs is throttling down by order of magnitude. For example, lets say after 5 failed login attempts, you lock the user for 10 seconds. Now, in order to bruteforce a single account, the attacker is limited to 30 attempts per minute - which makes it not feasible to break strong passwords - assuming your users passwords are strong enough, which brings up the question of password policy, or better yet - password generation and entropy. So, yeah, it's a Sec.SE q.
    – AviD
    Feb 26, 2015 at 21:28

4 Answers 4


This is security, not UX. The only reasonable lockout time is the minimum time needed for security reasons. There is no use in adjusting that for UX purposes. You are asking for a "reasonable" time frame so it should be a reason explainable to the user. But what would the explanation be? A few absurd examples:

For a shorter time frame than necessary:

"We made our application easier to break into just to make things easier for you"

For a longer time frame than necessary:

"There is no need to lock you out any longer but you still have to wait some more"

But seriously you should discuss a time frame with the person that made the decision for the lockout and try to convince him to keep it as short as security allows.

  • 5
    +1 the answer to any question of the form "How much should I inconvenience users?" is always "As little as possible". The question is how little is possible without creating problems. Feb 26, 2015 at 18:48
  • @user568458 you are absolutely right and that is exactly the purpose of my question.
    – Okavango
    Feb 26, 2015 at 20:11
  • @Okavango in that case, if your question is "how little is enough for security purposes?" you should be asking on Information Security. Also, see my comments on the q....
    – AviD
    Feb 26, 2015 at 21:29

What's the goal for the lockout, without knowing that it's hard to advise on appropriate timings.

Are you still seeing dictionary attacks after implementing your other measures? How long do those attacks last? How long does a genuine user leave it before trying to log in again? (i.e. what is your users average time between visits).

If you know all those things, you can calculate a sensible time for your lockout. Anyone who gives an answer without knowing those things is just sticking their finger in the air and making a guess.

Your lockout, if you're determined to have one, should be shorter than the average time between repeat visits for genuine users, and longer than the amount of time the dictionary attacks you're actually seeing take.


We are implementing a temporary account lockout after throttling login attempts and actively directing users to reset their password.

Why do you try to get users to reset their passwords if it wasn't compromised? This doesn't seem like a good idea from a usability point (its annoying to change passwords), or security (if you make me change my passwords too often, I might go for weaker passwords, because I cannot remember so many new good passwords).

Users can still go through the reset journey even during temporary lockout!

Why not allow them to reset the account lockout, but keep their password?

Are we dealing with minuets or hours?

If you do decide on temporary account lockouts (instead of no lockouts, or permanent lockouts which can be reset via email, which both seem like better alternatives), make it minutes at a maximum. Depending on the service your website offers, locking users out for hours can range from annoying to completely unacceptable. It also doesn't really add all that much security (limiting bruteforce attacks to 3 attempts per 5 minutes for example - in addition to all other functionality you could implement to make bruteforcing harder[*] - should be more than enough to slow down any attack).

And if you do make temporary lockouts, I would make the time depended on the amount of lockouts. One example might be: first lockout for 1 minute after 5 failed attempts, second lockout for 2 minutes after 3 more failed attempts, third lockout for 5 minutes after 3 more failed attempts.

[*] block users by IP/other identifying data, captchas after x wrong attempts, reasonable password policy, etc.

  • 1
    It seems like a good idea to me. Note they're not forcing people to reset passwords, they're allowing and encouraging people who have failed to log in repeatedly to do so, during the security-mandated lock period. Resetting a password isn't fun, but it's quicker and easier than waiting minutes or hours for a lock to expire, or calling customer services - but those options are still available for users not in a hurry. Feb 27, 2015 at 9:37

While I agree that this is probably better suited for the Security SE, there is a user experience aspect to consider.

What is it that you're protecting? What true value does your site hold for its users?

If I enter my password wrong on my banking website and am locked out for 24 hours, I am annoyed, but also a bit relieved that the security surrounding such important information is solid. Part of me is grateful that my bank is taking extra steps to protect my information.

Now, if I were to be locked out of my Reddit account for 24 hours because of too many password attempts, that would actually be more annoying. I don't see my Reddit account as a valuable asset, and therefore don't understand why it should be under such lock and key.

For the end user, it comes down to perspective. Can you justify protecting the content behind the lockout? The more valuable (but less time sensitive) the user sees the information as, the more understanding they can be of heightened security.

  • 2
    but what if you have to use your banking website now, because you have to pay bills, and if you pay in 24 hours, you will have to pay late fees? That would be extremely annoying (probably enough that some people would switch banks because of it), it could be abused (I don't like person X, so I'll bruteforce their account all the time, so they cannot use online banking), and it doesn't even add that much security (banking generally has additional measures, such as TANs to avoid money being stolen).
    – tim
    Feb 26, 2015 at 19:16
  • 1
    Yes, that would be annoying, especially during a time crunch. Ultimately, that falls on me though as the user. Although, and I'm preaching to choir here, a lot of users aren't necessarily "reasonable" thinkers, so I get your point. Maybe a bank website was a poor example, but the point remains, the annoyance factor depends on the user's perceived value of what's being protected. If they can justify a lock down, then it's not a terrible idea. Feb 26, 2015 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.