Re: Account Lockout Policies

[Randy Marchany <marchany () CANDI2 CIRT VT EDU>]

> 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