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.

Improve this question
12
  • 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, 2017 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, 2017 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: security.stackexchange.com/questions/158075/…
    – Silver
    Apr 25, 2017 at 14:09
  • 1
    Sjoerd also shows that the question can be answered constructively.
    – Silver
    Apr 25, 2017 at 14:21
  • That question asks a defined question that can have a single acceptable answer. Yours does not.
    – schroeder ♦
    Apr 25, 2017 at 14:23

2 Answers 2

Reset to default
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.

Improve this answer
0
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.

Improve this answer
3
  • Not sure what you propose is a "decent" password policy
    – schroeder ♦
    Apr 25, 2017 at 13:47
  • We can drop the details and open another discussion?
    – Silver
    Apr 25, 2017 at 14:12
  • you are trying to jump start a discussion when I already explained why that wouldn't work
    – schroeder ♦
    Apr 25, 2017 at 14:33

Not the answer you're looking for? Browse other questions tagged .