[Freeipa-devel] global account lockout

[Simo Sorce]

On Mon, 2014-04-07 at 14:28 -0600, Rich Megginson wrote:
> On 04/07/2014 01:00 PM, Simo Sorce wrote:
> > On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote:
> >> On 04/07/2014 02:31 PM, Simo Sorce wrote:
> >>> On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote:
> >>>> On 04/07/2014 10:13 AM, Simo Sorce wrote:
> >>>>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote:
> >>>>>> 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.
> >>>>> Sigh re[plying again to myself.
> >>>>> note that the main issue with replicating failed accounts is that you
> >>>>> can cause replication storms by simply probing all user accounts with
> >>>>> failed binds or AS requests. In some environments that may cause DoSs
> >>>>> (if you have slow/high latency links on which replication runs for
> >>>>> example).
> >>>>> So I think we should always give the option to turn off failed
> >>>>> date/count attributes replication, which in turn would mean we still
> >>>>> require a new attribute to replicate for when a user is finally locked
> >>>>> out on one of the servers or we fail requirement 1.
> >>>>>
> >>>>> Simo.
> >>>>>
> >>>> Another problem with keeping track of bind attributes in a replicated
> >>>> environment is the sheer size of the replication metadata.  Replicating
> >>>> 1 failed bind attempt might be 100kbytes or more data to all servers.
> >>>> We should have a way to perhaps say "only keep last N CSNs" or maybe
> >>>> even "don't keep CSNs for these attributes".
> >>> Yes, but this look a lot like general replication improvement (would
> >>> also be cool to have "better" conflict resolution), not lockout
> >>> specific.
> >>>
> >>> Simo.
> >>>
> >> My only comment is actually about conflict resolution. What would happen
> >> if I attack (flood) two replicas at the same time beating the
> >> replication. It would mean both servers would generate the global
> >> attributes and try to replicate to each other. If the replicas are on
> >> the edges of topology it might take some time and it might even happen
> >> that admin already unlocked the account while the old lock is still
> >> trying to propagate. IMO we need collisions resolution logic taken care
> >> of first. I suspect that any real attack would lead to collisions and if
> >> it would leave the deployment unstable even after the attack ended we lost.
> > Yes, this is a valid concern. We need a last-wins conflict resolution
> > strategy for some cases.
> 
> I'm not sure what you mean.  The 389 conflict resolution strategy is 
> "last-wins" already.  Or do you mean "for some cases, but not all cases"?

I am thinking about those case when we end up with duplicate objects.
In many (most ?) case we should just throw away one of the 2 and keep
the other, not end up with 2 objects.

Simo.

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