Re: Account Lockout Policies

[jack suess <jack () UMBC EDU>]

I'd like to suggest people take a look at the eauthentication
assessment suite developed by NIST for the federal government. This
was designed for validating different levels of assurance between
federal agencies. One thing that the credential assessment suite
provides is a spreadsheet that allows you to examine different
password policies and their resulting strength.

We used this to discuss with our auditors how we were selecting our
password policy and showed that different tradeoffs produce
equivalent password practices.

NIST did a very good job on the password spreadsheet. When you work
with the assessment matrix you can show that some standard audit
practices don't help very much. We used this to show that changing
passwords more frequently is not necessarily better than requiring
stronger passwords at the beginning.

Inside this you can play with account lockout rules and determine the
benefit that comes from different approaches.

For more on eauthentication, www.cio.gov/eauthentication
For the credential assessment suite http://www.cio.gov/
eauthentication/CredSuite.htm

jack suess
On Jul 12, 2006, at 5:50 PM, Russell Fulton wrote:

> Valdis Kletnieks wrote:
> > On Tue, 11 Jul 2006 16:07:30 EDT, Randy Marchany said:
> > > > 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 :-).
> >
> > If anybody cares, one of the earliest cites on login attempts is
> > probably
> > the DoD 'Rainbow Series' manual on password management (April
> > 1985).  It's
> > important to note that at least in this manual, the *goal* (limit the
> > upper bound of guesses) is clearly understood - I'm not convinced
> > that most
> > auditors have as good a grasp on the *why* as the Rainbow Series
> > guys did.
>
> [ Lots of good stuff snipped ]
>
> This is where monitoring of logs suddenly becomes vitally
> important.  If
> you review your authenication records regularly for failed logins (you
> do don't you ?) then you only have to slow down the log in attempts so
> it is unlikely that an attacker can brute force an account before it
> (the attack) is noticed.  Of course all your passwords should
> conform to
> standards ;) but seeing a persistent brute force attack against an
> account is a good reason to make quite sure that the account is
> 'safe'.
>
> This is why authentications services without logging mechanism are a
> total disaster (MS are you listening, remember RDP?)
>
> Russell