What I am trying to avoid here is brute force attacks on a user's password. And I am thinking about doing that by invalidating his password when too many attempts are made in the same minute, hour, day or something similar. The user credentials are for company employees on the road in an Android app.

But, at the same time, I do not want the user to make a few mistakes while inserting it and have it invalidated without any need.

How much is enough? Or, in alternative, how do I determine how much is enough?

Asking in another way, what is the maximum of mistakes a human can possibly do while inserting his password before contacting helpdesk?

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


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.
  • CAPS lock is also possible on a mobile (SwiftKey, the keyboard on my mobile device, has a caps lock key). – A.L Feb 14 '15 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 '15 at 21:32
  • 1
    This answer is excelent. Thank you very much @dnbrv – Alexandre Martins Feb 14 '15 at 21:48
  • @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 '15 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 '15 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 '15 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. – Alexandre Martins Feb 13 '15 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. – Andrew Martin Feb 13 '15 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 – Alexandre Martins Feb 13 '15 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 '15 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. – Alexandre Martins Feb 13 '15 at 14:20
  • How touch gestures prevent brute force attack? A bot can try all the possible solutions too. – A.L Feb 14 '15 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 '15 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 '15 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. – Alexandre Martins Feb 13 '15 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. – the other one Feb 16 '15 at 8:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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