[Freeipa-devel] global account lockout

[Simo Sorce]

On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote:
> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote:
> > Ludwig Krispenz wrote:
> > > Hi,
> > >
> > > please review the following feature design. It introduces a global
> > > account lockout, while trying to keep the replication traffic minimal.
> > > In my opinion for a real global account lockout the basic lockout
> > > attributes have to be replicated otherwise the benefit is minimal: an
> > > attacker could perform (maxFailedcount -1) login attempts on every
> > > server before the global lockout is set. But the design page describes
> > > how it could be done if it should be implemented - maybe the side effect
> > > that accounts could the be unlocked on any replica has its own benefit.
> > >
> > > http://www.freeipa.org/page/V4/Replicated_lockout
> > 
> > One weakness with this is there is still a window for extra password 
> > attempts if one is clever, (m * (f-1))+1 to be exact, where m is the 
> > number of masters and f is the # of allowed failed logins.
> 
> Yes, but that is a problem that cannot be solved w/o full replication at
> every authentication attempt.
> 
> What we tried to achieve is a middle ground to at least ease
> administration and still lock em up "earlier".

Let me add that we "could" have yet another closer step by finding a way
to replicate only failed attempts and not successful attempts in some
case. Assuming a setup where most people do not fail to enter their
password it would make for a decent compromise.

That could be achieved by not storing lastsuccessful auth except when
that is needed to clear failed logon attempts (ie when the failed logon
counter is > 0)

If we did that then we would not need a new attribute actually, as
failed logins would always be replicated.
However it would mean that last Successful auth would never be accurate
on any server.

Or perhaps we could have a local last successful auth and a global one
by adding one new attribute, and keeping masking only the successful
auth.

The main issue about all these possibilities is how do we present them ?
And how do we make a good default ?

I think a good default is defined by these 2 characteristics:
1. lockouts can be dealt with on any replica w/o having the admin hunt
down where a user is locked.
2. at least successful authentications will not cause replication storms

If we can afford to cause replications on failed authentication by
default, then we could open up replication for failedauth and
failedcount attributes but still bar the successful auth attribute.
Unlock would simply consist in forcibly setting failed count to 0 (which
is replicated so it would unlock all servers).
This would work w/o introducing new attributes and only with minimal
logic changes in the KDC/pwd-extop plugins I think.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York