The last piece of the puzzle when it comes to password policies is the account lockout . Also this is another area where a tighter policy doesn't necessarily lead to improved security. A lot of companies go for 3 incorrect attempts, and this does lead to a lot of lockouts on Monday mornings and consequently a lot of false positives in the security departments monitoring for attacks on authentication systems.
Again with this section of policy it's important to understand what threat is being mitigated. Account lockout is designed to mitigate online password guessing attacks.
Now given that if you have a password length of say 8 characters with a requirement for upper and lower case characters you've got a theoretical maximum of 52^8 combinations (reality will be obviously be somewhat less than that).
So realistically the risk of an online password guessing attack succeeding is pretty low, if the attacker doesn't have an insight into likely passwords that a user will choose.
So what's a good number for password lockout. Well Microsoft recommends 50, but I've got to say that I think around 10 is good for most circumstances. My reasoning here is that if someone can't remember their password after 10 goes, they've almost definitely forgotten it.
Of course the next part of this is what to do when you've locked the account out. Well if you've gone for a reasonably high setting on the incorrect password attempts, then I'd say in most cases lock the account permanently until the user has gone through the password reset procedure (establishing a good password reset procedure is a topic for another day!).
One problem with account lockout that's raised is the potential for Denial-Of-Service. If the username is predictable to an attacker they can iterate over the namespace and lockout all the accounts.
The mitigation for this depends on the architecture of the systems. If the system is inside a corporation then monitoring should track the attack and incident response should hopefully be able to track down the attacker.
However for Internet facing systems that's obviously not possible, so some other mitigation may be needed.
Two potential options for this are
- IP based lockout. Instead of locking the account for all users, only lock it for the source IP of the attack. This isn't perfect protection but may well work for many attackers
- Use multiple secrets. For example have a password and a secondary secret. Then only increment the incorrect login count if the attacker is getting the username and one of the secrets correct.
