Re: [Freeipa-devel] global account lockout
I came across these articles that may be of some use in this topic. I humbly admit that I am no expert on this topic, and these may not be of any use. Plus, I am not a fan of the product, but maybe it helps? http://technet.microsoft.com/en-us/library/cc772726%28v=ws.10%29.aspx http://blogs.technet.com/b/askds/archive/2010/08/18/fine-grained-password-policy-and-urgent-replication.aspx Gabe On Wed, Apr 9, 2014 at 8:40 AM, Ludwig Krispenz wrote: > > On 04/09/2014 04:17 PM, Rich Megginson wrote: > >> On 04/09/2014 08:09 AM, Simo Sorce wrote: >> >>> On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: >>> Something like this is what we have experienced for real and cause > us to > actually disable replication of all the lockout related attributes > in > the past. > But also here it can get complicated, we cannot really use failedlogincount and replicate it, eg if it is "2" on each server an their are parallel login attempts, we would increment it to "3" and replicate, so we would have 3 on all servers, not what we wanted. We could replicate changes to lastfailedauth and when receiving an update for this attribute locally increase failedcount, but it would also have to be used for resets (deleting lastFailedAuth), but there could also be race conditions, maybe there are other local attrs needed. >>> Yes, the current mechanism is deficient in many ways. For example the >>> failedcount/lastfailedauth attibutes are really suboptimal, a better >>> mechanism woul dbe to have a failedauths (not plural) multivalued >>> attribute and just append dates there (perhaps pre/postfixed with the >>> replica idto avoid any possible conflict). This way if 2 servers are >>> being attacked simultaneously they still should replicate their own >>> failure and each server can see that 5 dates are present in the last X >>> minutes and quickly lock the user, nor failedcount would be necessary >>> and no races incrementing it would occur. >>> >> >> This is an interesting idea. Please file a ticket in the 389 trac >> explaining this. >> >> >>> The only issue would be in cleaning up the attribute to not let it grow >>> to much, but that could be accomplished by simply *not adding any more >>> failed counts once the account is locked (only logging locally that >>> someone tried to log in on a locked account) and deleting the attribute >>> completely when the acocunt is unlocked, this again would reduce the >>> attributes necessary for handling locking own to 1 from the current 3 >>> (lastsuccessauth/lastafiledauth/failedcounter) however it still does >>> nothing to solve replication issues and has other replication races >>> problems (not sure what happens if a server try store a new failed auth >>> date and the other is deleting the old values at the same time. >>> Perhaps deleting by value is safe enough and won't cause issues, >>> Deleting the whole attribute may cause issues instead). >>> >> >> Handling of simultaneous updates of multi-valued attributes and update >> resolution works well. >> >> >>> And the bad news: I claimed that the replication protocol ensures that the last change wins except for bugs, and looks like we have one bug for single valued attributes in some scenarios. I have to repeat the test to double check. The update resolution code for single valued attrs is a nightmare, Rich and I several times said we need to rewrite it :-( >>> Is there a ticket that tracks this and explains the issue(s) ? >>> >> >> https://fedorahosted.org/389/ticket/47442 >> > my scenario was slightly differenent, without modrdn, but delete:oldvalue, > add:newvalue[i] on three servers i=1,2,3 "simultaneously" > > >> >>> Simo. >>> >>> >> > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/09/2014 04:17 PM, Rich Megginson wrote: On 04/09/2014 08:09 AM, Simo Sorce wrote: On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: Something like this is what we have experienced for real and cause us to actually disable replication of all the lockout related attributes in the past. But also here it can get complicated, we cannot really use failedlogincount and replicate it, eg if it is "2" on each server an their are parallel login attempts, we would increment it to "3" and replicate, so we would have 3 on all servers, not what we wanted. We could replicate changes to lastfailedauth and when receiving an update for this attribute locally increase failedcount, but it would also have to be used for resets (deleting lastFailedAuth), but there could also be race conditions, maybe there are other local attrs needed. Yes, the current mechanism is deficient in many ways. For example the failedcount/lastfailedauth attibutes are really suboptimal, a better mechanism woul dbe to have a failedauths (not plural) multivalued attribute and just append dates there (perhaps pre/postfixed with the replica idto avoid any possible conflict). This way if 2 servers are being attacked simultaneously they still should replicate their own failure and each server can see that 5 dates are present in the last X minutes and quickly lock the user, nor failedcount would be necessary and no races incrementing it would occur. This is an interesting idea. Please file a ticket in the 389 trac explaining this. The only issue would be in cleaning up the attribute to not let it grow to much, but that could be accomplished by simply *not adding any more failed counts once the account is locked (only logging locally that someone tried to log in on a locked account) and deleting the attribute completely when the acocunt is unlocked, this again would reduce the attributes necessary for handling locking own to 1 from the current 3 (lastsuccessauth/lastafiledauth/failedcounter) however it still does nothing to solve replication issues and has other replication races problems (not sure what happens if a server try store a new failed auth date and the other is deleting the old values at the same time. Perhaps deleting by value is safe enough and won't cause issues, Deleting the whole attribute may cause issues instead). Handling of simultaneous updates of multi-valued attributes and update resolution works well. And the bad news: I claimed that the replication protocol ensures that the last change wins except for bugs, and looks like we have one bug for single valued attributes in some scenarios. I have to repeat the test to double check. The update resolution code for single valued attrs is a nightmare, Rich and I several times said we need to rewrite it :-( Is there a ticket that tracks this and explains the issue(s) ? https://fedorahosted.org/389/ticket/47442 my scenario was slightly differenent, without modrdn, but delete:oldvalue, add:newvalue[i] on three servers i=1,2,3 "simultaneously" Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/09/2014 08:09 AM, Simo Sorce wrote: On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: Something like this is what we have experienced for real and cause us to actually disable replication of all the lockout related attributes in the past. But also here it can get complicated, we cannot really use failedlogincount and replicate it, eg if it is "2" on each server an their are parallel login attempts, we would increment it to "3" and replicate, so we would have 3 on all servers, not what we wanted. We could replicate changes to lastfailedauth and when receiving an update for this attribute locally increase failedcount, but it would also have to be used for resets (deleting lastFailedAuth), but there could also be race conditions, maybe there are other local attrs needed. Yes, the current mechanism is deficient in many ways. For example the failedcount/lastfailedauth attibutes are really suboptimal, a better mechanism woul dbe to have a failedauths (not plural) multivalued attribute and just append dates there (perhaps pre/postfixed with the replica idto avoid any possible conflict). This way if 2 servers are being attacked simultaneously they still should replicate their own failure and each server can see that 5 dates are present in the last X minutes and quickly lock the user, nor failedcount would be necessary and no races incrementing it would occur. This is an interesting idea. Please file a ticket in the 389 trac explaining this. The only issue would be in cleaning up the attribute to not let it grow to much, but that could be accomplished by simply *not adding any more failed counts once the account is locked (only logging locally that someone tried to log in on a locked account) and deleting the attribute completely when the acocunt is unlocked, this again would reduce the attributes necessary for handling locking own to 1 from the current 3 (lastsuccessauth/lastafiledauth/failedcounter) however it still does nothing to solve replication issues and has other replication races problems (not sure what happens if a server try store a new failed auth date and the other is deleting the old values at the same time. Perhaps deleting by value is safe enough and won't cause issues, Deleting the whole attribute may cause issues instead). Handling of simultaneous updates of multi-valued attributes and update resolution works well. And the bad news: I claimed that the replication protocol ensures that the last change wins except for bugs, and looks like we have one bug for single valued attributes in some scenarios. I have to repeat the test to double check. The update resolution code for single valued attrs is a nightmare, Rich and I several times said we need to rewrite it :-( Is there a ticket that tracks this and explains the issue(s) ? https://fedorahosted.org/389/ticket/47442 Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: > > Something like this is what we have experienced for real and cause > us to > > actually disable replication of all the lockout related attributes > in > > the past. > But also here it can get complicated, we cannot really use > failedlogincount and replicate it, eg if it is "2" on each server an > their are parallel login attempts, we would increment it to "3" and > replicate, so we would have 3 on all servers, not what we wanted. > We could replicate changes to lastfailedauth and when receiving an > update for this attribute locally increase failedcount, but it would > also have to be used for resets (deleting lastFailedAuth), but there > could also be race conditions, maybe there are other local attrs > needed. Yes, the current mechanism is deficient in many ways. For example the failedcount/lastfailedauth attibutes are really suboptimal, a better mechanism woul dbe to have a failedauths (not plural) multivalued attribute and just append dates there (perhaps pre/postfixed with the replica idto avoid any possible conflict). This way if 2 servers are being attacked simultaneously they still should replicate their own failure and each server can see that 5 dates are present in the last X minutes and quickly lock the user, nor failedcount would be necessary and no races incrementing it would occur. The only issue would be in cleaning up the attribute to not let it grow to much, but that could be accomplished by simply *not adding any more failed counts once the account is locked (only logging locally that someone tried to log in on a locked account) and deleting the attribute completely when the acocunt is unlocked, this again would reduce the attributes necessary for handling locking own to 1 from the current 3 (lastsuccessauth/lastafiledauth/failedcounter) however it still does nothing to solve replication issues and has other replication races problems (not sure what happens if a server try store a new failed auth date and the other is deleting the old values at the same time. Perhaps deleting by value is safe enough and won't cause issues, Deleting the whole attribute may cause issues instead). > And the bad news: I claimed that the replication protocol ensures that > the last change wins except for bugs, and looks like we have one bug > for single valued attributes in some scenarios. I have to repeat the > test to double check. > The update resolution code for single valued attrs is a nightmare, > Rich and I several times said we need to rewrite it :-( Is there a ticket that tracks this and explains the issue(s) ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/09/2014 07:57 AM, Petr Spacek wrote: On 9.4.2014 15:50, Ludwig Krispenz wrote: On 04/09/2014 12:31 AM, Simo Sorce wrote: On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: Replication storms. In my opinion the replication of a mod of one or two attribute in a entry will be faster than the bind itself. Think about the amplification effect in an environment with 20 replicas. 1 login attempt -> 20+ replication messages Now think about what happen bandwidth wise when a few thousand people all authenticate at the same time across the infrastructure, you deploy more servers to scale better and you get *more* traffic, at some point servers actually get slower as they are busy with replication related operations. Think what happen if one of these servers is in a satellite office on a relatively slow link and every morning it receives a flooding of replication data ... that is 99% useless because most of tat data is not relevant in that office. ok, lets leave it with that, there might be scenarios where it becomes unacceptable and as long as we have an acceptable solution we need not enforce full replication If an attacker knows all the dns of the entries in a server the denial of service could be that it just does a sequence of failed logins for any user and nobody will be able to login any more, This is perfectly true which is why we do not permanently lockout users by default and which is why I personally dislike lockouts. A much better mechanism to deal with brute force attacks is throttling, but it is also somewhat harder to implement as you need to either have an async model to delay answers or you need to tie threads for the delay time. Still a far superior measure than replicating status around at all times. yes, that could be a good solution, but not trivial replication would help to propagate this to other servers, but not prevent it. This would also be the case if only the final lockout state is replicated. Yes but the amount of replicated information would be far less. With our default 1/5th less on average as 5 is the number of failed attempts before the final lockout kicks in. So you save a lot of bandwidth. I like the idea of replicating the attributes changed at failed logins (or reset) only. I think this is reasonable indeed, the common case is that users tend to get their password right, and if you are under a password guessing attack you should stop it. The issue is though that sometimes you have misconfigured services with bad keytabs that will try over and over again to init, even if the account is locked, or maybe (even worse) they try a number of bad keys, but lower than the failed count, before getting to the right one (thus resetting the failed count). If they do this often you can still self-DoS even without a malicious attacker :-/ Something like this is what we have experienced for real and cause us to actually disable replication of all the lockout related attributes in the past. But also here it can get complicated, we cannot really use failedlogincount and replicate it, eg if it is "2" on each server an their are parallel login attempts, we would increment it to "3" and replicate, so we would have 3 on all servers, not what we wanted. Maybe it is totally of topic, but ... could something like Modify-Increment Extension http://tools.ietf.org/html/rfc4525 help? (I don't know how replications works, this would help only if it replicates operations and not only results of modifications.) Replication does replicate the operation. It essentially just "forwards" the modify operation received by the initial server, along with some replication meta-data. I meant - it would replicate an command to increment the value by 1 instead of replicating the new value. The problem is that servers would quickly get out of sync. I'm not sure how we would ensure eventual convergence. Petr^2 Spacek We could replicate changes to lastfailedauth and when receiving an update for this attribute locally increase failedcount, but it would also have to be used for resets (deleting lastFailedAuth), but there could also be race conditions, maybe there are other local attrs needed. And the bad news: I claimed that the replication protocol ensures that the last change wins except for bugs, and looks like we have one bug for single valued attributes in some scenarios. I have to repeat the test to double check. The update resolution code for single valued attrs is a nightmare, Rich and I several times said we need to rewrite it :-( PS: Martin, if you are looking for subjects for a thesis, maybe some theoretical model for replication update resolution and what is required history could be a challenge. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing
Re: [Freeipa-devel] global account lockout
On 9.4.2014 15:50, Ludwig Krispenz wrote: On 04/09/2014 12:31 AM, Simo Sorce wrote: On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: Replication storms. In my opinion the replication of a mod of one or two attribute in a entry will be faster than the bind itself. Think about the amplification effect in an environment with 20 replicas. 1 login attempt -> 20+ replication messages Now think about what happen bandwidth wise when a few thousand people all authenticate at the same time across the infrastructure, you deploy more servers to scale better and you get *more* traffic, at some point servers actually get slower as they are busy with replication related operations. Think what happen if one of these servers is in a satellite office on a relatively slow link and every morning it receives a flooding of replication data ... that is 99% useless because most of tat data is not relevant in that office. ok, lets leave it with that, there might be scenarios where it becomes unacceptable and as long as we have an acceptable solution we need not enforce full replication If an attacker knows all the dns of the entries in a server the denial of service could be that it just does a sequence of failed logins for any user and nobody will be able to login any more, This is perfectly true which is why we do not permanently lockout users by default and which is why I personally dislike lockouts. A much better mechanism to deal with brute force attacks is throttling, but it is also somewhat harder to implement as you need to either have an async model to delay answers or you need to tie threads for the delay time. Still a far superior measure than replicating status around at all times. yes, that could be a good solution, but not trivial replication would help to propagate this to other servers, but not prevent it. This would also be the case if only the final lockout state is replicated. Yes but the amount of replicated information would be far less. With our default 1/5th less on average as 5 is the number of failed attempts before the final lockout kicks in. So you save a lot of bandwidth. I like the idea of replicating the attributes changed at failed logins (or reset) only. I think this is reasonable indeed, the common case is that users tend to get their password right, and if you are under a password guessing attack you should stop it. The issue is though that sometimes you have misconfigured services with bad keytabs that will try over and over again to init, even if the account is locked, or maybe (even worse) they try a number of bad keys, but lower than the failed count, before getting to the right one (thus resetting the failed count). If they do this often you can still self-DoS even without a malicious attacker :-/ Something like this is what we have experienced for real and cause us to actually disable replication of all the lockout related attributes in the past. But also here it can get complicated, we cannot really use failedlogincount and replicate it, eg if it is "2" on each server an their are parallel login attempts, we would increment it to "3" and replicate, so we would have 3 on all servers, not what we wanted. Maybe it is totally of topic, but ... could something like Modify-Increment Extension http://tools.ietf.org/html/rfc4525 help? (I don't know how replications works, this would help only if it replicates operations and not only results of modifications.) I meant - it would replicate an command to increment the value by 1 instead of replicating the new value. Petr^2 Spacek We could replicate changes to lastfailedauth and when receiving an update for this attribute locally increase failedcount, but it would also have to be used for resets (deleting lastFailedAuth), but there could also be race conditions, maybe there are other local attrs needed. And the bad news: I claimed that the replication protocol ensures that the last change wins except for bugs, and looks like we have one bug for single valued attributes in some scenarios. I have to repeat the test to double check. The update resolution code for single valued attrs is a nightmare, Rich and I several times said we need to rewrite it :-( PS: Martin, if you are looking for subjects for a thesis, maybe some theoretical model for replication update resolution and what is required history could be a challenge. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/09/2014 12:31 AM, Simo Sorce wrote: On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: Replication storms. In my opinion the replication of a mod of one or two attribute in a entry will be faster than the bind itself. Think about the amplification effect in an environment with 20 replicas. 1 login attempt -> 20+ replication messages Now think about what happen bandwidth wise when a few thousand people all authenticate at the same time across the infrastructure, you deploy more servers to scale better and you get *more* traffic, at some point servers actually get slower as they are busy with replication related operations. Think what happen if one of these servers is in a satellite office on a relatively slow link and every morning it receives a flooding of replication data ... that is 99% useless because most of tat data is not relevant in that office. ok, lets leave it with that, there might be scenarios where it becomes unacceptable and as long as we have an acceptable solution we need not enforce full replication If an attacker knows all the dns of the entries in a server the denial of service could be that it just does a sequence of failed logins for any user and nobody will be able to login any more, This is perfectly true which is why we do not permanently lockout users by default and which is why I personally dislike lockouts. A much better mechanism to deal with brute force attacks is throttling, but it is also somewhat harder to implement as you need to either have an async model to delay answers or you need to tie threads for the delay time. Still a far superior measure than replicating status around at all times. yes, that could be a good solution, but not trivial replication would help to propagate this to other servers, but not prevent it. This would also be the case if only the final lockout state is replicated. Yes but the amount of replicated information would be far less. With our default 1/5th less on average as 5 is the number of failed attempts before the final lockout kicks in. So you save a lot of bandwidth. I like the idea of replicating the attributes changed at failed logins (or reset) only. I think this is reasonable indeed, the common case is that users tend to get their password right, and if you are under a password guessing attack you should stop it. The issue is though that sometimes you have misconfigured services with bad keytabs that will try over and over again to init, even if the account is locked, or maybe (even worse) they try a number of bad keys, but lower than the failed count, before getting to the right one (thus resetting the failed count). If they do this often you can still self-DoS even without a malicious attacker :-/ Something like this is what we have experienced for real and cause us to actually disable replication of all the lockout related attributes in the past. But also here it can get complicated, we cannot really use failedlogincount and replicate it, eg if it is "2" on each server an their are parallel login attempts, we would increment it to "3" and replicate, so we would have 3 on all servers, not what we wanted. We could replicate changes to lastfailedauth and when receiving an update for this attribute locally increase failedcount, but it would also have to be used for resets (deleting lastFailedAuth), but there could also be race conditions, maybe there are other local attrs needed. And the bad news: I claimed that the replication protocol ensures that the last change wins except for bugs, and looks like we have one bug for single valued attributes in some scenarios. I have to repeat the test to double check. The update resolution code for single valued attrs is a nightmare, Rich and I several times said we need to rewrite it :-( PS: Martin, if you are looking for subjects for a thesis, maybe some theoretical model for replication update resolution and what is required history could be a challenge. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On Tue, 2014-04-08 at 12:00 +0200, Ludwig Krispenz wrote: > Replication storms. In my opinion the replication of a mod of one or > two attribute in a entry will be faster than the bind itself. Think about the amplification effect in an environment with 20 replicas. 1 login attempt -> 20+ replication messages Now think about what happen bandwidth wise when a few thousand people all authenticate at the same time across the infrastructure, you deploy more servers to scale better and you get *more* traffic, at some point servers actually get slower as they are busy with replication related operations. Think what happen if one of these servers is in a satellite office on a relatively slow link and every morning it receives a flooding of replication data ... that is 99% useless because most of tat data is not relevant in that office. > If an attacker knows all the dns of the entries in a server the > denial of service could be that it just does a sequence of failed > logins for any user and nobody will be able to login any more, This is perfectly true which is why we do not permanently lockout users by default and which is why I personally dislike lockouts. A much better mechanism to deal with brute force attacks is throttling, but it is also somewhat harder to implement as you need to either have an async model to delay answers or you need to tie threads for the delay time. Still a far superior measure than replicating status around at all times. > replication would help to propagate this to other servers, but not > prevent it. This would also be the case if only the final lockout > state is replicated. Yes but the amount of replicated information would be far less. With our default 1/5th less on average as 5 is the number of failed attempts before the final lockout kicks in. So you save a lot of bandwidth. > I like the idea of replicating the attributes changed at failed logins > (or reset) only. I think this is reasonable indeed, the common case is that users tend to get their password right, and if you are under a password guessing attack you should stop it. The issue is though that sometimes you have misconfigured services with bad keytabs that will try over and over again to init, even if the account is locked, or maybe (even worse) they try a number of bad keys, but lower than the failed count, before getting to the right one (thus resetting the failed count). If they do this often you can still self-DoS even without a malicious attacker :-/ Something like this is what we have experienced for real and cause us to actually disable replication of all the lockout related attributes in the past. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
Looks like there was a great discussion while I was away :-) There seem to be great concerns (and mybe confusion) about replication update resoultions, conflicts and amount of meta data stored. I think it's not as bad as you may think. Large amounts of metadata can only accumulate for multivalued attributes, for single valued attributes only the latest value and in some cases one! previous value is stored. For multivalued attributes the amount of data were considerably reduced with the fix for #569 The replication protocol and its update resolution is designed to follow a single master model: the final result should be the same as if the modifications were applied in the order of the csns on a single master, this implies that the last change wins. T There are some cases where conflicting entries or conflict attributes are generated. conflict entries should only be generated if the same entry (dn) is concurrently added on different masters. Conflict attribute are only genrated in some rare corner cases. In the case of krbLastFailedAuth or krbFailedLoginCount always the value with the highest csn will win, no scenario for a conflict. Replication storms. In my opinion the replication of a mod of one or two attribute in a entry will be faster than the bind itself. If an attacker knows all the dns of the entries in a server the denial of service could be that it just does a sequence of failed logins for any user and nobody will be able to login any more, replication would help to propagate this to other servers, but not prevent it. This would also be the case if only the final lockout state is replicated. I like the idea of replicating the attributes changed at failed logins (or reset) only. Regards, Ludwig On 04/08/2014 12:56 AM, Simo Sorce wrote: 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 stor
Re: [Freeipa-devel] global account lockout
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 actu
Re: [Freeipa-devel] global account lockout
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"? He may be thinking entry vs attribut
Re: [Freeipa-devel] global account lockout
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"? Simo. __
Re: [Freeipa-devel] global account lockout
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 accou
Re: [Freeipa-devel] global account lockout
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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/07/2014 12: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), Ludwig has made some improvements with how 389 stores replication metadata for conflict resolution, but in this case it's not nearly enough. not lockout specific. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
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. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
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". ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
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. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
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". Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
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. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] global account lockout
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
