On Tue, Jan 27, 2009 at 9:28 AM, Howard Chu <hyc(a)symas.com&gt; wrote: True, a legitimate user that has forgotten their password will try multiple times with different passwords. However it's still a small set of different passwords they would be trying. Contrast that with a crack attempt where someone would try with a different password every time. Let's say that we set the limit at 50. Its unlikely that a legitimate user would try with more than 50 different passwords. They'd just give up after some small number and file a ticket to have it reset. A crack attempt on the other hand would easily cross that limit. In our case, the usual problem has been that someone changes their password, they don't change their password on all the machines they use to access corp resources. So some mail client somewhere keeps trying to login with the same old password, and locks them out because the application doesn't have the sense to stop trying after a failed attempt. In general though, repeated failed attempts with a small set of passwords isn't indicative of a crack attempt. Multiple attempts with different passwords is. Aravind.

On Tue, Jan 27, 2009 at 12:14 PM, Clowser, Jeff <jeff_clowser(a)fanniemae.com&gt; wrote: Yup, exactly. Well.. I can't speak for performance, I am not familiar enough with the code base to really even attempt this myself. Implementing this as another overlay module should limit the impact it has on core code? As to the security vulnerability, combining this with a policy that says you are not allowed to re-use previous passwords should help mitigate that. Aravind.

Kurt Zeilenga wrote: thought My thinking exactly. But then, if they are encrypted and protected the same as the password history and userpassword attributes, that might mitigate this particular risk to an extent, especially if you sync your users passwords across all systems, as many corps do (Don't get me wrong, I still see this as risky and I can think of many ways it may be misused...) Without a doubt. But... I think what Aravind was getting at was a way to reduce the potential for (particularly unintentional) DoS "attacks" - cases such as clients that store an old password and then lock out a user, etc. We get tickets for that all day here as well... Actually, I'd say most if not all of out password lockout issues are from this rather than genuine attacks, but we still have to implement password policies like this "just in case" and follow up on each case (we're a rather prime target here...) I will say that if such an enhancement *were* to be implemented, it would probably eliminate almost all our false positives and only lock out users for extreme cases and genuine attacks... - Jeff

Aravind Gottipati wrote: I'm wondering if that's even necessary. According to your description so far, it would be sufficient to only store 1 failed password. If as you say, the same password is tried multiple times, then this should be good enough. Feature requests are treated like anything else. http://www.openldap.org/its/ And again, the Project is run on a volunteer basis. If no one in the community is interested in writing code for this feature, it will be ignored. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

Why not just raise the max tries to, say, 100? -- Kurt On Jan 28, 2009, at 2:28 PM, Clowser, Jeff wrote:

On Wed, Jan 28, 2009 at 2:52 PM, Kurt Zeilenga <Kurt(a)openldap.org&gt; wrote: Because, that does not solve the problem. Here is an example. User A may have used passwords P1, P2, P3 in the past and he may have a few commonly used passwords P4 and P5 as well (that he uses for other sites). Lets say P1 is the current password on the system. Lets say MaxFailureAttempts is set to 100. User A changed the password, but forgot to update the some applications (some of which he doesn't use often). Some of these applications may still be (storing and) using P2 or P3 even. In the current system, if one of these applications continues to try to repeatedly login with any of P1 through P5 it will lock him out after 100 attempts. In the modified system, since he is only trying a few of these P1, P2, P3 (or even P4 and P5), there is no reason to lock him out. This is clearly not a crack attempt, since he is only trying these few passwords multiple times. A crack attempt on the other hand will quickly run over MaxFailureAttempts with different passwords. I logged a new bug in the ITS form, but it didn't spit back a bug number at me. I outlined the scheme Jeff proposed earlier which would probably work very well for a system like this. Aravind.

--On January 28, 2009 3:43:59 PM -0800 Aravind Gottipati <aravind(a)freeshell.org&gt; wrote: Your bug submission gets emailed to you, with the ITS number in the subject. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

At this point, I'm playing devils advocate a bit. I'm not 100% sure I'm sold on this myself, but it's definitely an attempt to deal with a problem I face daily, so I'm continuing this to fully explore the idea. tried enough. A brute force attack varies the password. A user having their app save a password and forgetting to change it doesn't - that retries the same password over and over. A brute force attack that uses the same password over and over is pointless, since it will never succeed if it failed the first time, so multiple failed attempts using the same password is not a threat to the password. The idea of locking an account after too many tries is to prevent a brute force attack and really comes down to a need to stop too many tries with *different* passwords. Locking a user that has an old password configed in their app that retries that over and over is not really a security issue that we need to stop (you want to stop it for other reasons, but not because it's a security risk). Locking accounts in these cases (same password over and over) is really a negative side effect of attempting to stop brute force attacks that most password policy plugins suffer from. So the root of the problem is not to stop N failed attempts, per se, but to stop someone trying N or more *different* passwords to break in. I.e. differentiating between these user cases, which are a problem but are not an "attack", and an actual brute force attack on the users password. While apps that can save passwords and users that use that feature are questionable from a security POV, it's what we have. Having a way to differentiate and only lock due to the attack case would without a doubt be useful. This isn't "broken" software (it doesn't violate any spec or standard). Questionable "feature" from a security POV, yes, but not "broken" (and it's supported by most client apps out there, unfortunately...) Whether we agree that it's a good feature or not (I don't consider it to be good), it's a very real problem that won't ever go away. here is no use N is there is It's not that a user will use N different passwords. It's differentiating between the attack, which uses N different passwords, and the bad user that uses the same password N times (because the had some client app save their password, then changed it without fixing the app). then to in at allow they need The key is to differentiate between the two, and be able to lock in the case of the cracker, but not the bad user (even if both are happening at the same time). If both *are* happening at the same time, it has to catch the attack - so if we see one process attempting many different passwords and at the same time see the same password being used over and over, it has to be able to lock because of the changing passwords. So tracking just the last password tried would not be sufficient, I don't think. Tracking the last pwdMaxFailure *unique* failed passwords that were attempted would, I think. I think once you hit pwdMaxFailure (or when the account is locked), you can stop recording things - once it's locked, you can't bind as it, so we don't have to track toward a lockout event. If the attack continues after we unlock it, it will quickly be locked again with minimal risk. the The timestamp is to determine whether the password attempts occured within the window of time that matters, and to ignore/purge those that happen outside of it, and allow things to unlock after some period of time. My thinking is that this would be in place of pwdFailureTime - i.e. instead of storing all the timestamps alone, what would matter is to just store the password hash and the last time that password was tried. If it accumulates too many values, the account may be locked. But instead of counting all failures, we just count the number of *unique* failures (and we need the password hash to implement the uniqueness, and the timestamp to see if it happened within pwdFailureCountInterval). Effectively, it means before updating pwdFailureTime, we look in that to see if this password is listed there. If it is, we update the timestamp, instead of adding another value. If not, we add it with the current timestamp. Everything else probably works about the same as it does now. need for If the account is locked out, how does one successfully log in? 1) if the password is reset. 2) after some amount of time has passed (pwdFailureCountInterval). 3) ?... through yet Let me rephrase. What I should have said was I have not discussed this with enough people to see if anyone else has thought of something I haven't, so I'm throwing this out for that discussion. At this point, I think I've thought it through enough - but do have concerns about the storage of these attempted passwords and the performance/complexity of implementing it that others may improve upon (or show good reason why this really is a bad idea :) This is where my hesitation towards this idea comes from). there's event. So values. That's pwdMaxFailure *unique* attempts - that is a significant distinction. And yes, once you hit pwdMaxFailure unique failed attempts - i.e. once the account is locked, you don't necessarily need to even process bind requests until the account is unlocked. is password anyway. The point of this discussion is to enhance the password lockout policy to still work as intended (to stop brute force attacks), while ignoring the "user has an old password configed in an app somewhere, which is not really an attack" case. - Jeff

Aravind Gottipati wrote: I closed that ITS because we viewed it as a security liability, not as a feature worthy of implementing. I think that conclusion was already clear from the earlier mailing list discussion. In this case, we've done a fair bit of tweaks in the ppolicy code recently. Your suggestions were not missed due to lack of time, they were rejected due to lack of technical merit. Generally, we implement features according to the published specs. If you believe this feature is valuable, you should push to have it included in the next version of the ppolicy draft. I've been pushing for a few additions recently as well. http://www.openldap.org/lists/ietf-ldapext/200907/msg00001.html Follow the Contributing guidelines if you want the code considered for inclusion. Of course since folks at Zytrax are the actual authors, they're the ones who will have to do the actual submission. http://www.openldap.org/devel/contributing.html But again, nothing is going to happen without buy-in from other reviewers and adoption into the published draft. I suspect that in its current form, no one is going to back this idea though because it is fundamentally unsound. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

On Sun, Jul 12, 2009 at 10:53 PM, Howard Chu&lt;hyc(a)symas.com&gt; wrote: Howard, You are right that it's not correct for apps to continue trying to authenticate with an incorrect password, or for them to fail silently. In a perfect word this would not happen. Unfortunately, we can't control all these apps or user's behaviors. My choices are to either ignore the problem and lock folks out after X failed attempts (whether real of from faulty apps), or, not even implement any sort of lockouts. I am not sure how else I can explain this to you, but it's a real problem and saying, "fix your apps" doesn't always work. Aravind.

Just want to make a few points here: - I think we can all agree that these apps are broken and that the first and best approach is to try to get these apps fixed. In an ideal world, that would be the only solution needed. Unfortunately, most of us don't live in an ideal world, and it's simply not possible to fix this in every application across an enterprise, or to select only apps that do passwords right (generally, that doesn't even make it on the requirements list...). As an alternative, it is reasonable to find a way to deal with it at a centralized point - the directory. That's part of the benefit of centralizing things. - Creating separate user accounts for separate apps a user uses defeats many of the benefits of a centralized directory. One security benefit being that a user has one account/id for all apps, such that deleting that one account entry takes away all their access. If we start creating multiple account entries for users, you lose this and risk "forgetting" to terminate one of their many accounts, making this multiple IDs for each user idea more of a security risk, not less. May as well go back to decentralizing the directory back into each app. It may not be an ideal place to fix it, but it is a practical one. And yes, it has to be separate accounts/entries, since these apps are doing binds to the directory to auth (i.e. can't create separate attributes for custom ID's/passwords). - Consider this example - the place I run into this most often is our Internet proxies, which are password protected. There are many apps a user uses that connects through the proxy (which in turn auths against ldap) to get some kind of content or update. Some of these (broken) apps provide users an option to save the password, and when they do (not that I recommend this behavior, but I can't stop them), it tries repeatedly to get updates/content using the old password after a user changes their password. If I set a unique id for the proxy for these apps, the user would have to use this for *all* their apps that access the web. I could allow both this unique id and their "normal" id access to the proxy, but the end result is that users would forget this less used id and just enter their "normal" id and password everywhere, which puts us back to the original problem. (And please don't say this is a user training issue - we all know that's rarely effective in the real world...) So, this is not really a practical suggestion. - The entire point of locking an account after some number of failed attempts is for one and only one purpose: To stop a brute force attack on a users password, which to succeed means trying many *different* passwords until the correct one is guessed. Retrying the same wrong password over and over will never succeed, so is not a security risk. So the *concept* of ignoring repeats of a wrong password introduces no security risk. I don't see how this in any way weakens any guarantee in the security policy. - So, the only "risk" is that of storing the hash of the failed attempts. I've seen arguments, the strongest of which is that this is bad because the failed password they tried *might* be used elsewhere. But consider that password history *is* supported. In my experience, users tend to rotate through a set of passwords they can remember, and use the same passwords on multiple systems, so it is far more likely that the passwordhistory will contain a password that they use elsewhere. This failed password hash cache (for lack of a better term) may also store passwords used elsewhere as a result, but will also include finger fumbles, etc that are not used anywhere. This password cache is also typically less long lived than passwordhistory (it goes away with a successful bind). So I'd argue that this password cache is *less* of a risk than passwordhistory, which is deemed acceptable. If these failed password cache attributes are properly protected by aci's, etc, they are just as safe (or more so) than passwordhistory. Some may argue that this is a user problem (using the same password between systems) and the fix is user education, but remember: we live in the real world, so nothings gonna stop this user behavior. - If we want to be really paranoid, in cases where someone accidentally passes a password for another system to my directory, from a users POV they have no idea what my server did with that password. So the mere fact that they sent it to my directory means I *could* conceivably have it. Whether I store it in a cache to prevent false lock events or not is irrelevant as far as they know - they've sent their password to someplace that shouldn't have it, and that someplace has now "seen" their password for the other system. Plus, without knowing what that other system is or the userid on that system, the password doesn't really help me. I'd probably be far more likely to break into other systems trying the same id (or email addr) and password they have in my directory on these other systems. (Again, users don't always do smart things. Security policy can only account for stupid user behavior to a point...) - The mozilla sponsored ppolicy enhancement makes this duplicate failed password check optional. Those that feel it's too much of a security risk can leave it off and use the old behaviour. Those that feel comfortable using it can do so. But we have that. It is: Lock any account where more than x consecutive unique failed passwords attempts are seen. This being changed from: Lock any account where more than x consecutive failed passwords attempts are seen. So there is still a clear policy, and no exceptions. Introducting the "unique" part in concept poses no risk, as shown above. - Jeff

The proxies cache *successful* authentication requests. unsuccessful authentication requests (i.e. failed logins) actually *supports* this idea rather than refutes it. You're just suggesting doing the same thing at the proxy that was suggested to be done at the directory - if you're gonna do this, may as well help the entire enterprise instead of just some small part of it. Another disadvantage of doing it at the proxy is that you never see the failed binds at the centralized auth service (the ldap server), so have no central log of the true number of failed attempts. (In the mozilla ppolicy, even if a failed bind is ignored for lockout purposes, I believe it still logs the failed attempt). - Jeff