Lockout

[Nicolas Williams]

On Tue, Sep 15, 2009 at 08:56:47PM +0200, Luke Howard wrote:
> For review:
> 
> 	http://k5wiki.kerberos.org/wiki/Projects/Lockout

 - Comment #1

"
Replication

...

For LDAP backends, we always attempt to update the lockout count; we
assume the LDAP client library can chase referrals, or that it is
multi-master. Ideally the administrator should be able to configure some
attributes on the LDAP server as non-replicated, but doing so is
vendor-specific. 
"

I don't know about OpenLDAP, but Mozilla libldap does not automatically
chase referrals.  Also, it's the DS that has to be multi-master, no?  In
any case, I think it's simpler to just say that in the LDAP case you
assume that the server is smart enough to ensure replication and
atomicity.  (Note that LDAP does provide for some degree of atomicity.)

 - Comment #2

What's really desired here is a way to slow down password guessing
attacks.  Account "lockout" is just what this technique evolved from.

If we look at "account lockout" from this p.o.v. then we see that we
don't really need to replicate any of the account lockout principal
record fields -- replication would only add to the infrastructure's
burden and would only marginally help in the real goal.  But we must not
forget about the other kind of password guessing attack: where the
attacker is trying to guess usernames and passwords, or has a list of
usernames and is trying to guess passwords for any one of them.

Detecting password guessing attempts per-principal is easy because we
already have a record to base it on (in the KDB).  Detecting password
guessing attempts spread across multiple principals is clearly harder
(and the available responses more limited), but probably worth doing as
a follow on.

Which brings me to:

 - Comment #3

Do we really need to write the account lockout fields to the KDB?  It
seems like a waste of time, literally -- assuming that KDB writes
involve fsync()s, doing any such writes will surely increase latency,
quite likely significantly so.

Of course, keeping account lockout state in memory is not necessarily
the right answer either, not without a fixed size to the in-core account
lockout DB and LRU/LFU eviction.  The necessary code infrastructure is
missing from the KDC, so the KDB approach is clearly the most expedient.

Can you characterize the impact on KDC performance of account lockout?

Yes, flash devices can be used to accelerate synchronous writes, so one
shouldn't mind any extra fsync()s here.  But it seems worth noting.

Nico
--