Account lockout support in Solaris 10 when authenticating againstKerberos

[Russ Allbery]

Nicolas Williams <Nicolas.Williams at sun.com> writes:

> Slowing down folks who are trying to guess passwords is a good thing.
> Letting them lock out all your user accounts is not.  The folks in
> charge of writing corporate security policies need to take this into
> account.  N-strikes-you're-locked is bad.  N-strikes-we-slow-you-down is
> good.

Yup, exactly.

This is one of those "features" that keeps showing up in commercial
products because it made it into some management checklist, but I really
don't think account lockout is a good idea in practice, at least without a
lot of safeguards.  Among other things, should you get a really
*interesting* attacker (the scariest kind), it provides a great secondary
attack channel to interfere with your ability to stop whatever they're
trying to do.  For example, the attacker could use some selective
"password guessing attempts" to lock the accounts of all of your
administrators before they start launching their real attack.

In practice, if you're just trying to stop dictionary attacks, dictionary
attacks are generally launched through a service that happens to
authenticate passwords against Kerberos, not at Kerberos directly.
Running one of the standard "block an IP address in iptables if they have
too many failed ssh logins" programs would get 95% of it at a typical Unix
shop, and I'm sure there are equivalents for other similar applications.

If you really worry about people smart enough to do direct dictionary
attacks against the KDC (which is very sophisticated as attackers
generally run), you can implement something similar by watching the KDC
logs for an inordinate number of TGT requests from a particular IP address
and start either delaying their packets or blocking that IP address
specifically.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>