Account Lockout - Has Time Passed It By?

When I first got into the cybersecurity arena, I read all the books that I could find on the subject. There weren't many back then in 1991. A number of the books dealt with securing Unix systems and they all had a section on Account Lockouts. Fast forward to the present and I'm finding myself at odds with the "standard" audit checklist requirement that says you must enable account lockouts. When I teach a SANS class and we touch on this subject, I like to ask my students a couple of questions:

1. How many of you enable account lockouts?
2. What's the purpose of the lockout?
3. Do you have strong password strength rules that are enforced?
4. What's the purpose of the strong password strength rules?
5. Do you monitor login fail/succeed entries?
6. What's the purpose of monitoring login attempts?
7. Do you notify an offending site that they're attacking you?
   
8. How long is the lockout period? Minutes? Days?
9. How long does it take to reset the account?

Almost everyone said they enable account lockouts and the purpose of the lockout was to prevent brute force password attacks. 90% of the students replied that they have strong password strength rules (and they enforce them :-)) and the purpose of the rules is to prevent brute force password attacks. Surprisingly, about 40-50% say they monitor login failures and/or successes. Those that do say they do this to detect brute force password attacks. 20-25% said they notify an offending site that some host in their domain is attacking them. I found this stat a little disturbing but that's a subject of another post. The account lockout period ranged from 1 minute to "forever". The reset time had pretty much the same time range as the account lockout period.

So, what's the problem? Suppose my attack is simply to lock out all of the accounts on the target. In the Unix world, a good sysadmin would prevent remote root logins and use the su and sudo commands to switch into root mode. An account lockout on their account would force them to drive to their operations center and physically walk up to the server to log in as root. An attacker could take advantage of this time delay to launch their attack. This happened to me back in 1997.

Back in the old days of Unix (late 80's-early 90's), Unix did not have password strength controls built into the OS. There were tools like npasswd, passwd+ that allowed such control but you had to build the commands manually. The absence of such controls left account lockouts as the only viable defense against a brute force password attack.

Nowadays, password strength rules enforcement is built into the OS usually in the form of PAM modules. The admin has a wide variety of builtin tools to mitigate brute force password attacks.

One of the things I always ask my admins is "does the security control introduce a worse problem than what we're trying to solve?" I believe account lockouts do just that. A massive DOS attack against your user base is worse than someone brute forcing their way into an account. Your password strength rules, log monitoring, notifying remote sites provide adequate defenses against a brute force attack. IMHO, account lockouts are an archaic solution to the problem. It's what I call an "inherited security solution". It was in an 1st edition security book and left in there with each new security book without realizing other controls are better.

IT Audit checklist will usually flag the lack of a lockout strategy as an audit item. It's time to update those checklists.