I am trying to prevent brute force attacks on a user's account by invalidating a password when too many attempts are made in the same minute, hour, day or something similar. The credentials in this scenario are for company employees on the road, and are used on an Android app.

At the same time, I do not want the user to have their password needlessly invalidated because they made a few mistakes.

How many attempts are enough? Or, alternatively, how do I determine how many are enough?

Asking in another way, what is the maximum number of mistakes a human should be allowed to make before contacting the helpdesk?

Edit: The authentication mechanism is done through the network. The app gets updated information from a company server after the user logs in successfully.

4 Answers 4


This question has been asked multiple times throughout the StackExchange network over the years. Here's a summary of answers:

  • There's no clear research on the subject.
  • If you're in the financial industry and have to be PCI compliant, the limit is 6 attempts.
  • A brute force attack can be recognized using an algorithm. Follow this guide to create an algorithm detecting automated password attempts.
  • Account lock-outs and password attempts limits are put in place to prevent human attackers guessing passwords based on their knowledge of the victim.


  • Microsoft recommends at least 4 attempts and no more than 10.
  • Don't count duplicate password attempts (they probably thought they mistyped it)
  • Make the password hint about the primary password, and don't have a (weak) secondary
  • Allow a trusted party to vouch for the user, so he can change his password.
  • Lock the account in increasing time increments
  • Remind the user of password rules.
  • Lock accounts out for 30 minutes instead of disabling them completely.
  • Instead of locking accounts, present the user with additional security questions.
  • Check for CAPS lock being on (not an issue on mobile though).

See the complete discussion Why do sites implement locking after 3 failed password attempts? on Security.SE.

My personal recommendations

I deal a lot with a poorly-designed system where people frequently forget their credentials because they don't use the system often enough to remember them. The system automatically locks user accounts after (I believe) 5 unsuccessful attempts. The lock requires a member of my team to go to the management console, reset the user password manually, and send them an email also manually with the temporary password. The amount of time wasted is horrible, but the system is provided by a vendor and we can't change it.

Whichever system, protocol, and workflow you use, you have to make sure that your users in the field don't have the luxury to wait even 15 minutes to restore access to their account. Thus, you have to create some self-service reactivation process. It could be as simple as sending an email to the user with a password reset link.

Also, keep track of all system status indicators:

  1. Credentials have not been accepted
  2. Email with password reset instructions has been sent.
  3. The number of attempts left until the account is locked.
  4. Account locking notification and a brief descriptions of what to expect next.
  • 1
    CAPS lock is also possible on a mobile (SwiftKey, the keyboard on my mobile device, has a caps lock key).
    – A.L
    Feb 14, 2015 at 12:12
  • 1
    "Don't count duplicate password attempts (they probably thought they mistyped it)" Just make sure to store the hash, not the plaintext password!
    – bjb568
    Feb 14, 2015 at 21:32
  • 1
    This answer is excelent. Thank you very much @dnbrv Feb 14, 2015 at 21:48
  • 1
    @A.L: While CAPS lock is available on mobile devices, it's less of a problem than on PCs/laptops because virtual keyboards indicate quite clearly when the case or the layout are switched.
    – dnbrv
    Feb 14, 2015 at 21:50
  • 1
    @dnbrv I agree with you, but I think that if an user can enable CAPS lock on a desktop keyboard and forget it, he can do this on a virtual keyboard too. For example with SwiftKey CAPS loke is indicated by a key with a different keyboard, you can easily miss it.
    – A.L
    Feb 14, 2015 at 22:34

Rather than simply invalidating the password it might be worth implementing a similar strategy to the one that Android uses in it's own system:

From memory I believe it uses a rule of 5 attempts before instituting a 5 minute lock-out. If another 5 failed attempts occur then the lock out time increases (I'm not sure what to as I've never failed that second attempt).

  • Andrew this is a very valid approach. I would add that at each failed attempt actively direct the user towards reset mechanism (via user-friendly message) to avoid lockout.
    – Okavango
    Feb 13, 2015 at 11:35
  • Sorry for not making it clear. The app accesses privileged information and the authentication mechanism is done against an authentication server. Not in the app itself. And we want the employees to get back into the app as soon as possible. I elieve the 5 minutes wait is not an option. Besides, we don't mind allwing the user 50 attempts. Or 100. As long as it is a low enough number to prevent brute force to work. Feb 13, 2015 at 11:58
  • From what you're saying, I don't think there is an upper limit. However, no-one wants to try the same failing login 100 times in a row. There two things I would suggest: on the first failure it might be a good idea to alert users to the existence (and the phone number of) the helpdesk by way of a note along with the failure notice. Secondly, I would suggest that the end users will probably have strong ideas on how many times they would try before contacting the helpdesk - That should be your guide number. Feb 13, 2015 at 14:20
  • Hmmm. Both suggestions are on the spot. Maybe asking the users is the best way. I wish there were some rough numbers from previously done studies. Thanks Feb 13, 2015 at 14:28
  • @AlexandreMartins: If you invalidate a user's password, resetting it will take longer than 5 minutes on ice to prevent brute force attack.
    – dnbrv
    Feb 13, 2015 at 16:27

Maybe you should try something different? For example in iPads and probably other Apple mobile devices for three invalid login tries you gets 5 minute penality and for every next try you gets that penality longer.

Also there are more and more mobile apps which are not using typed password but some touch gestures instead. This solution eliminates brutal force hacking method completely.

  • Regarding the 5 minute penalty, it might not fit the use case since these are employees of our company on the road. The point about gestures is really good. Thank you. Feb 13, 2015 at 14:20
  • How touch gestures prevent brute force attack? A bot can try all the possible solutions too.
    – A.L
    Feb 14, 2015 at 12:06
  • I didn't know that there are bots that can pretend gestures on touch screen. But isn't there some solutions for preventing that? For example we can use some kind of randomness to place UI elements? It can be still recognizable for users but every time we put it in a different, random place. So it makes brutal force method much slower and unprofitable. We know that brute force works always. we can only make it slower.
    – jazzgot
    Mar 9, 2015 at 12:08
  • Also, look at table up here: blogs.msdn.com/b/b8/archive/2011/12/16/… Touch gestures makes few time more posible combinations.
    – jazzgot
    Mar 11, 2015 at 12:36

From a usability perspective? Infinite. With help being clearly highlighted to the user.

From a security perspective? That's one for the security stack exchange really. Though Andrew's answer seems good.

  • Infinite is a very large number. But the best number might come from the users themselves as Andrew says. Feb 13, 2015 at 14:29
  • theoretically infinite, I wouldn't expect anyone to actually try beyond double digits! But from a usability POV locking someone out because they make mistakes is terrible design. They should be allowed to try as much as they want. Its only due to security (which is a very valid concern) things are as they are. Feb 16, 2015 at 8:11

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.