Account-lock security policy (username/password)

Question

I am currently working on an application with regard to applying a security policy to the application. We are locking the account after X failed login attempts in Y minute. The account will be locked for Z minutes. I want to know whether the account should be locked if there are successive failed login attempts or that the account should be locked if there are failed attempts within the past Y minutes.

Example: failed login attempts = 3 within 10 mins

If the user enters the wrong username/password 2 times. Then logs in successfully the 3rd time. He then logs out and attempts a failed login.(All the attempts are within the 10 minutes.)

Should the account be locked or not?

Answer 1

There is no right or wrong answer. The more aggressive lockout policy is slightly more secure, and slightly less convenient for your users. You have to assess if it is worth doing based on your application's requirements, your knowledge of your user base, the value of the asset you are protecting, your threat model, etc. etc.

Answer 2

And always remember there might be idiots who are trying to DOS someone they do not like by purposely trying to lock his account out using known email account.

Answer 3

Yes, the account should be locked out.

The reason is that the successful login could be from the real user, and the failed logins could be from an attacker. The fact that the real user has logged in should not reset the counter for the attacker. Of course you could track sessions and only lock out the user if they are on a different session than the real user, however here there is more risk of implementation bugs meaning you could inadvertently introduce something that allows an attacker to work around the lockout. With security it is often best to keep things as simple as possible.

You should also rate limit repeated attempts from the same IP address as that will help protect against a horizontal attack against different user accounts.

The above is comment on your current proposal, however I would also go for an increasingly delayed response rather than locking out.

e.g.

Login Attempt              Artificial Delay
1                          0
2                          1 second
3                          2 seconds
4                          4 seconds
5                          8 seconds

That way the real user will be able to log in during a brute force on their account and the attacker cannot cause a Denial of Service on the legitimate user. For longer delays you could display something to the user to show that their login is in progress so they would not be tempted to click again. Of course you do not want the maximum delay to be much longer than several seconds, however adding an artificial delay across threads will delay an attacker. The difference between slowing down login and showing an account locked out message is that the real user will not have to keep submitting their login details - they just need to be patient while login is progressed.