Educause Security Discussion mailing list archives
Re: Account Lockout Policies
From: Randy Marchany <marchany () CANDI2 CIRT VT EDU>
Date: Tue, 11 Jul 2006 16:07:30 -0400
We use 3 attempts before lockout, but the duration is short. The point is to stop automated attempts and random guessing so I don't see much point in locking "forever".
Time to become the pinata :-). I have always thought that a denial-of-service attack was much more dangerous than password enumeration attacks. If you ask yourself "what is the real goal of this lockout?" (well, to detect brute force password attacks, of course) and "is there another way to mitigate this attack?" (yes, look at your logs!), you find that lockouts are dangerous. 1. Password enumeration attacks generate multiple Login Failed messages. A good event log (logparser) or syslog scanner (logcheck) will alert the appropriate staff of the attack. A string of Login Failed messages in a very short period of time is a good clue that something amiss is happening. You discover the brute force attack is in progress. IF (big capital IF) you have good password strength rules, AND (big capital AND) you do some sort of password strength testing, let them do the enumeration attacks. Nothing is lost except some cycles. If the VP/Pres/CIO/CFO/Provost's accounts gets locked, you lose a lot of goodwill. It stresses the help desk when 2000 users hit them with password reset questions. Do lockouts really defeat automated password attacks? I doubt it. If it's automated, it won't care if the acct is locked or not. If my real goal is to lock out accounts and maybe gain access to the random account with a guessable password, then you've made my job easier. 2. Account lockout is a historical (yes, I have grey hair) solution to what was back then an almost intractable problem. Back in the old day, we had no way to really enforce password strength rules on accounts. We had no other way to null route the attackers or any of the myriad defenses we have today. I do believe it's an anachronism. 3. We had an attack a couple of years ago where the hackers intentionally locked out accounts in order to buy time to launch their attacks. When you configure your system to not accept root/admin logins from remote locations AND your normal account is locked, you have to drive to the office. That's time that the hackers have to do their thing. Since then, I've questioned the effectiveness of the account lockout. So, while most audit checklists recommend account lockouts, remember that those docs are not set in stone and can be modified. If you believe the DOS on your system is a more serious threat, then consider doing away with lockouts and spend your time on other responses. Just my .02 worth. Swing away! -Randy Marchany VA Tech IT Security Office VA Tech Blacksburg, VA 24060 marchany () vt edu
Current thread:
- Account Lockout Policies Saburo Usami (Jul 11)
- <Possible follow-ups>
- Re: Account Lockout Policies Eric Brewer (Jul 11)
- Re: Account Lockout Policies Graham Toal (Jul 11)
- Re: Account Lockout Policies Cheek, Leigh (Jul 11)
- Re: Account Lockout Policies Valdis Kletnieks (Jul 11)
- Re: Account Lockout Policies Cheek, Leigh (Jul 11)
- Re: Account Lockout Policies Randy Marchany (Jul 11)
- Re: Account Lockout Policies Gary Flynn (Jul 11)
- Re: Account Lockout Policies Gary Dobbins (Jul 11)
- Re: Account Lockout Policies Valdis Kletnieks (Jul 11)
- Re: Account Lockout Policies Russell Fulton (Jul 12)
- Re: Account Lockout Policies jack suess (Jul 12)
- Re: Account Lockout Policies Gary Flynn (Jul 13)
- Re: Account Lockout Policies Jonny Sweeny (Jul 14)
- Re: Account Lockout Policies Graham Toal (Jul 14)