We are going to add an additional layer of security to our product by locking user accounts for a short period of time (configurable in the product, but probably 5-10 minutes) when a user has tried to log in unsuccessfully a number of times (also configurable, but the default setting will probably be around 5 times).

I am now trying to figure out how best to present this to the user.

Option A: Count down the number of attempts left every time the users makes an unsuccessful attempt to log in. E.g. "You have 3 login attempts left", "You have 2 login attempts left" etc. The problem with this approach, as I see it, is that it adds an unnecessary and possibly stressful component to the login process. On the other hand people will probably be less sloppy when entering their passwords if they are informed immediately after the first error that they only have so many attempts before the account is locked.

Option B: Only present a warning before the final attempt. E.g. "For security reasons your user account will be locked for X minutes if you enter the wrong credentials again." This approach avoids unnecessary information until the user actually needs it and I am leaning towards this option.

What are your thoughts? Is there another, better way?

  • 1
    Is there any control for password recovery? Commented Sep 11, 2012 at 7:50
  • Yes, there is a password recovery feature. Commented Sep 11, 2012 at 8:15
  • 1
    Is there any mechanism in place that would stop a malicious person from deliberately entering invalid credentials in order to lock a user's account? Commented Sep 11, 2012 at 11:59
  • Nope. :) But I cannot really think of a way to prevent that. I am open for ideas here. The extra security is something that we must have. This is an e-learning product and we have had situations where students have been able to guess teachers passwords after a number of tries. But you are absolutely right, this will enable evil students to deliberately lock teacher accounts if they figure out that this functionality is in place. Commented Sep 11, 2012 at 13:22
  • 1
    @Henrik By doing that, you've basically created a way to inform the cracker that he's found the right password on the 106th attempt, and now all he has to do is wait for the lockout to expire and he's in.
    – jkindwall
    Commented Mar 29, 2019 at 14:45

4 Answers 4


TL;DR - Most of the time I've seen people add this feature it's been pure security theatre. It hasn't helped the user and doesn't make the site safer. Avoid if possible.

The long version...

Personally - I'd start questioning whether this was actually a good feature to add. Is it actually making the system more secure? Are there better ways to make it secure?

Here I'm assuming that it's a web based application. I'm assuming the login is pure username/email & password. Some of this doesn't apply if those two assumptions are incorrect.

  • Are people actually trying to crack the system? Is this addressing a real problem - or one that people think is going to happen / happening? If the latter then I would fight very hard for there to be evidence that this was a problem before adding the feature. Once place I worked with was sure they were getting hacking attacks because of large numbers of failed password attempts. On investigation it turns out they just had a lot of users forgetting their passwords... A different client found out it was a spamming bot that was posting e-mail addresses and URLs to the login boxes. Be sure first. User lock outs add little security, add risk (see below), and makes the users job more stressful.

  • If you add an account lockout you have immediately made the site open to a denial of service attack. Remember most serious cracking attacks are mass attacks targeted at the site in general, not targeted attacks at individuals. They'll be trying thousands/millions of username/password combinations. Suddenly you have thousands of users locked out of their accounts. This causes a roll-on effect that overloads your support centre with calls/emails. This causes your support to fall over. This causes people to bitch and moan about how lousy the service is. Welcome to PR hell. I've seen this happen twice now :-)

  • Lock outs don't help in most instances. Since cracking attempts are mostly mass attacks the crackers won't care. They'll just move on to the next account and come back N minutes later and carry on.

If it is happening there are much better techniques to solve it than a simple failed-login-attempt counter being exceeded. For example a combination of all of the following:

  • On the Nth attempt start introducing an additional authentication technique. A birthday, a CAPTCHA (one of the few times I think they're a reasonable option :-), answer to a security question, etc. By adding a third piece of information you make it harder to for crack attacks.

  • Start directing users towards the password reset mechanism so they have an automated mechanism to recover the password they have obviously forgotten.

  • Rather than lock people out start introducing pauses into the login process. Make the initial pauses short, make the pauses after multiple attempts longer. Throttling dramatically cuts down the risk since it forces the cracker bots to drop down the number of attempts to a human-scale, and that's not enough to get in guessing passwords at random.

  • Hmm. Some good points here. I have to talk to my team some more. Perhaps we are making a mistake introducing this. The thing is, we have had people trying to crack passwords, but not real cracker attacks. Just students trying to guess their teachers passwords. So something needs to be done. Commented Sep 13, 2012 at 9:25
  • 1
    I think this answer is much more in the UX category. From a UX standpoint, it's a dumb principle to not tell the user which thing they entered is incorrect but from a security standpoint, it may be Bad with a capital B. Similarly, from a user experience standpoint, you have to think about how the actual user will experience this. If I've forgotten my password or username, it's probably the result of too stringent security rules on your site. I get really annoyed when I get locked out (especially if I have to call someone to get unlocked).
    – Perchik
    Commented Apr 21, 2014 at 14:37

Standard security practice is not to divulge anything about the process while it's in progress. This is because it aids unauthorised attempts to access the system.

This may not be a particularly necessary consideration for a message like "You have two attempts left," but never tell the user how long the account will be locked out for. It gives away too much information about your security model.

Similarly, never give a hint about which token is wrong: whether the username is not recognised or the password isn't correct. A message saying the username is wrong tells a cracker* not to use it again; a message that the password is wrong tells him that the username is valid and he only needs to try passwords. Always give a generic "Invalid login" message.

None of this precludes offering help on recovering a lost password.

Instead of giving hints during the process, these things need to be communicated to new users during their induction training, and (if it's a new security regime introduced for existing users) either directly to users in a mailshot or as a system message once they're logged in.

*Yes, cracker, not hacker. Eric S Raymond on the difference

  • 2
    Whereas I agree with almost everything you have mentioned above, I fail to see any suggestions for a solution so far (correct me if I'm wrong please :-). I'm curious to hear your thoughts on how to handle this feedback. Commented Sep 11, 2012 at 8:00
  • 1
    In this case, you present to the user only the small amount of information necessary to indicate something has gone wrong. A link to online or telephone help would be useful. That is, the premise of the question, to give the users as much information as possible about what's going on, is wrong. Commented Sep 11, 2012 at 8:03
  • "never give a hint about which token is wrong". Good point. We only tell the user that the username or the password was wrong, so that is already covered. And I get the point about not divulging anything about the process or how long the account will be locked, but I just know that if we don't tell them, tech support will be overloaded with calls about how to reactivate accounts that may already have been activated. You see, this is a product that we sell. ... Commented Sep 11, 2012 at 8:21
  • ... Our clients are responsible for induction training etc. and they never do a very good job with it. What I am thinking is that the level of security can be raised according to the client's needs by setting the lock-out time to, say, 24 hours. They could still call support and have them unlock the account of course. Do you not think that would discourage most hackers/crackers enough to make them move on to easier targets? Commented Sep 11, 2012 at 8:21
  • I think security is paramount. If an account has already been re-activated (or can be re-activated for the user) then if you are confident about who you're talking to you can tell them the lockout period. That will head off future calls -- and the user can tell their colleagues too. But if your clients are responsible for training and aren't doing it then your support costs are necessarily increased (hint, hint!) Commented Sep 11, 2012 at 9:18

I'd say option B seems the most logical solution for me; as you said, Option A just adds a stressful component to the login process and telling me how many attempts I have left, will not at all make me remember my password faster.

I do have a suggestion for Option B though:

I don't know if I should mind the copy, but if so, I'd make it a lot shorter and to the point. And why not guide the user to a solution if possible? So don't just tell that there's one attempt remaining, also help that user retrieve their password if they have really lost it.

For example:

"For security reasons, you have 1 attempt remaining. Forgot your password?"

  • So there is a password recovery feature? Commented Sep 11, 2012 at 8:05
  • Good question, but I had only assumed that there is one. Alternatively, you could also link to a contact page. Commented Sep 11, 2012 at 8:10
  • Yes, there is a password recovery feature. I will not go into detail about that here, but Nicks suggestion is a good one. Commented Sep 11, 2012 at 8:11

Option C:

Let them make one error without anything happening. (which covers for the 'I know I made a typing error' situation)

Then on the second error show the Option A countdown sequence.

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.