1

Edit: As I am asked to clarify this question I will state it in one sentence: What is a good lockout policy for web applications, why, on what does it depend?

It is hard to find a best practice regarding account lockout policies. Windows suggests locking an account after 4 to 10 failed attempts

PCI uses the following minimum criteria:

  • User accounts are temporarily locked-out after not more than six invalid access attempts.
  • Once a user account is locked out, it remains locked for a minimum of 30 minutes or until a system administrator resets the account.

Drupal has the following defaults which are still used today:

Drupal 7 prevents brute force attacks on accounts. It blocks login b y a user that has more than 5 failed login attempts (within six hours) or an IP address that has more than 50 failed login attempts (within one hour).

Does anyone have any other best practices I can add? I would like to have an open discussion on the subject and try to find one set of guidelines for a decent lockout policy that balances security, usability, denial of service.

Silver
  • 1,824
  • 11
  • 23
  • What's your question? It looks like you want to start a discussion or list various policies, which is not a great fit here. – schroeder Apr 25 '17 at 13:47
  • 1
    My proposed "best balance" is not a lockout at all, but an exponentially increasing delay in allowing attempts that decays over time. If short enough at the start, a human would not notice, but automated systems would push into the massively long delays. – schroeder Apr 25 '17 at 13:51
  • What place do you suggest for a discussion? We can move this to chat and come with an answer here later. How is it different from this one in wanting to start a discussion: https://security.stackexchange.com/questions/158075/is-it-unsafe-to-show-message-that-username-account-does-not-exist-at-login/158082#158082 – Silver Apr 25 '17 at 14:09
  • 1
    Sjoerd also shows that the question can be answered constructively. – Silver Apr 25 '17 at 14:21
  • That question asks a defined question that can have a single acceptable answer. Yours does not. – schroeder Apr 25 '17 at 14:23
  • StackExchange is unique in that it is a Q&A site, not a discussion forum. Open-ended questions are just not a great fit. – schroeder Apr 25 '17 at 14:24
  • We could go to a chat room, but you have not asked a question for anyone to discuss. As for usability, that really depends on the UI and your users. There isn't going to be a single approach. – schroeder Apr 25 '17 at 14:26
  • https://security.stackexchange.com/questions/82844/limiting-login-attempts https://security.stackexchange.com/questions/82832/account-lock-security-policy-username-password – schroeder Apr 26 '17 at 06:49
  • As mentioned in other questions, it all depends on what you are trying to secure and why. For most web applications, you are trying to secure stranger's accounts. That means your policy is entirely a UX consideration. – schroeder Apr 26 '17 at 06:50
  • Can we than have answers based on these parameters? I want to advise web app builders on how to create such a policy with all these considerations and with the current info I can't give a well funded answer as all best practices seem to differ. It is not a specific case where I can say what they are trying to protect and who might attack but that doesn't make the question unfit for stackexchange? – Silver Apr 26 '17 at 06:56
  • It's too broad (and ultimately not about security). The reason "best practices" differ is because it all depends on the application and the threat analysis. This is not a great place to permute over all factors a designer could consider to set a policy. In the end, best practices and advice can only suggest broad upper bounds. – schroeder Apr 26 '17 at 07:00
  • I'll keep hoping someone will see the value of this question in the future. – Silver Apr 26 '17 at 07:15

2 Answers2

7

The NIST guidelines say this:

the verifier SHALL effectively limit online attackers to no more than 100 consecutive failed attempts on a single account.

100 attempts seem pretty high compared to your quoted five or six attempts. However, apparently NIST still thinks it is adequate. There is a big difference between "at most 100 attempts" and "an infinite number of attempts". Unless your password is "123456" or "qwerty" or "password", it takes many thousands of tries to brute-force a password.

At the same time, it is pretty common for users to type in their password incorrectly a number of times.

So I think it is best to set the limit pretty high, but since this balances security against usability I don't think there is a "correct" answer here.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
1

I feel like these guidelines are very restrictive, especially the Drupal one where you get locked for several hours. To me, the main goal of a lockout policy is to prevent password guessing. Therefor it can't be discussed without talking about password policies. In case of Drupal you can easily use reCaptcha which should help defend against automated attacks.

If we assume a decent password policy:

  • Min length 6 chars
  • Not in a password top 10 000 list
  • Not in/does not contain a custom created list (name of the company, username, data of birth, ...)

We would require over 10 000 password guesses to find a users' password. So why do we only allow 5 attempts? The same security can be obtained when allowing 20 or 50 attempts. A user can easily fill in 5 incorrect passwords and be locked which is decremental to To reach a limit of 50 you would probably use a tool.

I would advise for a more permissive lockout policy if combined with a decent password policy AND lack of user enumeration possibilities.

That's just my 2 cents, please comment and reply.

Silver
  • 1,824
  • 11
  • 23