[Freeipa-devel] global account lockout

[Dmitri Pal]

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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.