Hi,
The current password policy module can lock folks out after some configurable number of failed attempts. The module currently does not differentiate between a user failing with the same wrong password a bunch of times versus a crack attempt where someone tries multiple different wrong passwords. Are there any modules that take into account if the same password is being used a bunch of times or if multiple different passwords are failing? Could this be a useful feature worth requesting (if it doesn't exist already)?
Thank you,
Aravind.
Aravind Gottipati wrote:
Hi,
The current password policy module can lock folks out after some configurable number of failed attempts. The module currently does not differentiate between a user failing with the same wrong password a bunch of times versus a crack attempt where someone tries multiple different wrong passwords. Are there any modules that take into account if the same password is being used a bunch of times or if multiple different passwords are failing?
No.
Could this be a useful feature worth requesting (if it doesn't exist already)?
What makes you think a legitimate user who forgot their password won't try multiple times with different passwords? I.e., what makes you think you can distinguish a cracker from a legit user this way?
On Tue, Jan 27, 2009 at 9:28 AM, Howard Chu hyc@symas.com wrote:
What makes you think a legitimate user who forgot their password won't try multiple times with different passwords? I.e., what makes you think you can distinguish a cracker from a legit user this way?
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.
Aravind Gottipatu wrote:
On Tue, Jan 27, 2009 at 9:28 AM, Howard Chu hyc@symas.com wrote:
What makes you think a legitimate user who forgot their password
won't try
multiple times with different passwords? I.e., what makes you think
you can
distinguish a cracker from a legit user this way?
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.
How would you tell a legitimate user trying 20 different passwords from an attack that only tries 20 different passwords? You can't. If you feel 50 attempts is acceptable, because a real attack would quickly exceed that, why not set your policy pwdMaxFailure to lock after 50 failed attempts?
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.
Sounds like what you are saying is that rather than counting the number of failed attempts to bind, you want to count the number of failed unique passwords that were attempted - i.e. if you keep trying the same password over and over, it only counts as one, so clients with saved passwords don't constantly lock out accounts.
That would be nice, but I can't help but think (without having thought it out in detail) that there would be a gotcha to this - performance issue, security vulnerability saving all those attempted passwords, etc.
- Jeff
On Tue, Jan 27, 2009 at 12:14 PM, Clowser, Jeff jeff_clowser@fanniemae.com wrote:
Sounds like what you are saying is that rather than counting the number of failed attempts to bind, you want to count the number of failed unique passwords that were attempted - i.e. if you keep trying the same password over and over, it only counts as one, so clients with saved passwords don't constantly lock out accounts.
Yup, exactly.
That would be nice, but I can't help but think (without having thought it out in detail) that there would be a gotcha to this - performance issue, security vulnerability saving all those attempted passwords, etc.
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.
On Jan 27, 2009, at 12:14 PM, Clowser, Jeff wrote:
That would be nice, but I can't help but think (without having thought it out in detail) that there would be a gotcha to this - performance issue, security vulnerability saving all those attempted passwords, etc.
There is actually a significant security risk in keeping a history of such passwords. While they might be invalid at the DSA for authentication, they are likely valid elsewhere. That is, it quite likely that a user might enter passwords for related systems. So keeping long term (pass the authentication request) exposes the user to greater risk.
Of course, one should note that lockout mechanisms are a major target of DoS attacks...
-- Kurt
Kurt Zeilenga wrote:
On Jan 27, 2009, at 12:14 PM, Clowser, Jeff wrote:
That would be nice, but I can't help but think (without having
thought
it out in detail) that there would be a gotcha to this - performance issue, security vulnerability saving all those attempted passwords, etc.
There is actually a significant security risk in keeping a history of such passwords. While they might be invalid at the DSA for authentication, they are likely valid elsewhere. That is, it quite likely that a user might enter passwords for related systems. So keeping long term (pass the authentication request) exposes the user to greater risk.
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...)
Of course, one should note that lockout mechanisms are a major target of DoS attacks...
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
On Tue, Jan 27, 2009 at 2:01 PM, Clowser, Jeff jeff_clowser@fanniemae.com wrote:
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...
Yup, this is proving to be a pita for us. Folks login from multiple machines and get locked out when they forget to propagate their password changes to all those machines.
Also, I am not sure how this will be any greater security risk than the current system of storing a SSHA hash of the current password within LDAP? We could store similar hashes of all the passwords tried (upto pwdMaxFailure) and compare against that?
Short of actually coding this up myself, what can I do to move it along to at least a feature request that will be considered?
Thank you,
Aravind.
Aravind Gottipati wrote:
On Tue, Jan 27, 2009 at 2:01 PM, Clowser, Jeff jeff_clowser@fanniemae.com wrote:
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...
Yup, this is proving to be a pita for us. Folks login from multiple machines and get locked out when they forget to propagate their password changes to all those machines.
Also, I am not sure how this will be any greater security risk than the current system of storing a SSHA hash of the current password within LDAP? We could store similar hashes of all the passwords tried (upto pwdMaxFailure) and compare against that?
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.
Short of actually coding this up myself, what can I do to move it along to at least a feature request that will be considered?
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.
Also, I am not sure how this will be any greater security risk than the current system of storing a SSHA hash of the current password within LDAP? We could store similar hashes of all the passwords
tried
(upto pwdMaxFailure) and compare against that?
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.
The caveat to this is that if you have two or three or N different passwords tried (one by an app that has the old password, one because of a fat finger mistake, etc in no particular order), how do you know which one to store? I think you'd have to store a hash of all failed passwords tried within the window of time defined.
I'm thinking the values would look something like:
<timestamp>;{<scheme>}<hash>
The timestamp would be the most recent time this was seen, scheme is crypt/sha/ssha/etc matching whatever is in the userpassword attribute, and hash is the encrypted password.
If the number of values in this attribute exceed the number of max fails allowed, the account is locked. Timestamp is needed to eventually expire and remove it.
The problem I would be concerned about is if this was really under a brute force attack, the number of values in this attribute could grow very quickly. Would it be reasonable to only store the last pwdMaxFailure passwords tried? I think maybe it would, but haven't really thought it through yet.
Jeff
Why not just raise the max tries to, say, 100?
-- Kurt
On Jan 28, 2009, at 2:28 PM, Clowser, Jeff wrote:
Also, I am not sure how this will be any greater security risk than the current system of storing a SSHA hash of the current password within LDAP? We could store similar hashes of all the passwords
tried
(upto pwdMaxFailure) and compare against that?
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.
The caveat to this is that if you have two or three or N different passwords tried (one by an app that has the old password, one because of a fat finger mistake, etc in no particular order), how do you know which one to store? I think you'd have to store a hash of all failed passwords tried within the window of time defined.
I'm thinking the values would look something like:
<timestamp>;{<scheme>}<hash>
The timestamp would be the most recent time this was seen, scheme is crypt/sha/ssha/etc matching whatever is in the userpassword attribute, and hash is the encrypted password.
If the number of values in this attribute exceed the number of max fails allowed, the account is locked. Timestamp is needed to eventually expire and remove it.
The problem I would be concerned about is if this was really under a brute force attack, the number of values in this attribute could grow very quickly. Would it be reasonable to only store the last pwdMaxFailure passwords tried? I think maybe it would, but haven't really thought it through yet.
Jeff
Clowser, Jeff wrote:
Also, I am not sure how this will be any greater security risk than the current system of storing a SSHA hash of the current password within LDAP? We could store similar hashes of all the passwords
tried
(upto pwdMaxFailure) and compare against that?
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.
The caveat to this is that if you have two or three or N different passwords tried (one by an app that has the old password, one because of a fat finger mistake, etc in no particular order), how do you know which one to store?
When you get to the general case of 'N' the feature being discussed here is no longer relevant. The original hypothesis is that only a cracker will use N different passwords on N different login attempts. If a legitimate user is using N different passwords on N tries, then the hypothesis fails and there is no validity to this feature at all.
If in fact a legitimate user only tries with 1 password, repeatedly, then storing (a hash of) only the last attempted password will be sufficient to detect this.
If you're storing only 1 password, and a cracker is attempting to break in at the same time that the user is trying to login, then you might as well allow the lockout to occur, because it will get a sysadmin's attention and they need to respond to the attack anyway.
I think you'd have to store a hash of all failed passwords tried within the window of time defined.
Since there is already a counter for maximum number of failed attempts, the timestamp is superfluous.
If the number of values in this attribute exceed the number of max fails allowed, the account is locked. Timestamp is needed to eventually expire and remove it.
Removal should only occur when a successful login occurs. There's no need for a separate expiration period.
The problem I would be concerned about is if this was really under a brute force attack, the number of values in this attribute could grow very quickly. Would it be reasonable to only store the last pwdMaxFailure passwords tried? I think maybe it would, but haven't really thought it through yet.
Making security-related suggestions that you haven't fully thought through yet really isn't a good idea.
If you only allow pwdMaxFailure attempts before locking the account, there's no point in even examining any passwords subsequent to the lockout event. So no, there should never be a need to store more than pwdMaxFailure values.
But again, the point of this discussion is that when a legitimate user is trying to login, you shouldn't need to recognize more than 1 bad password anyway.
Ultimately I believe the original hypothesis is invalid, and this whole discussion is moot.
On Wed, Jan 28, 2009 at 2:52 PM, Kurt Zeilenga Kurt@openldap.org wrote:
Why not just raise the max tries to, say, 100?
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 Jan 28, 2009, at 3:43 PM, Aravind Gottipati wrote:
On Wed, Jan 28, 2009 at 2:52 PM, Kurt Zeilenga Kurt@openldap.org wrote:
Why not just raise the max tries to, say, 100?
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.
Sounds like these applications are broken.
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.
It seems these limits are giving you and your users far more pain than they ever will give an attacker.
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.
At the expense of the directory exposing the user to more risk. At the expense of more complexity in the directory (read, more risk). At the expense of resources to save and managing this history (read, more risk).
A crack attempt on the other hand will quickly run over MaxFailureAttempts with different passwords.
Right, A DoS attacker will lock out the user regardless given any sort of limit.
I logged a new bug in the ITS form, but it didn't spit back a bug number at me.
It's there. It was published to -bugs. As to what happen to the usual email to the submitter, I haven't a clue. Likely quarantined somewhere (not here).
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@freeshell.org wrote:
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.
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
--On January 28, 2009 4:26:35 PM -0800 Kurt Zeilenga Kurt@OpenLDAP.org wrote:
It's there. It was published to -bugs. As to what happen to the usual email to the submitter, I haven't a clue. Likely quarantined somewhere (not here).
I believe he expected after posting the bug to be taken to a web page that showed the bug and its bug number, which is what most modern bug tracking systems do, but not what jitterbug does, or at least, is not what it is configured to do. They likely had not checked their email after hitting submit.
--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.
Also, I am not sure how this will be any greater security risk than the current system of storing a SSHA hash of the current password within LDAP? We could store similar hashes of all the passwords
tried
(upto pwdMaxFailure) and compare against that?
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.
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.
When you get to the general case of 'N' the feature being discussed
here is no
longer relevant. The original hypothesis is that only a cracker will
use N
different passwords on N different login attempts. If a legitimate user
is
using N different passwords on N tries, then the hypothesis fails and
there is
no validity to this feature at all.
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).
If in fact a legitimate user only tries with 1 password, repeatedly,
then
storing (a hash of) only the last attempted password will be sufficient
to
detect this.
If you're storing only 1 password, and a cracker is attempting to break
in at
the same time that the user is trying to login, then you might as well
allow
the lockout to occur, because it will get a sysadmin's attention and
they need
to respond to the attack anyway.
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.
I think you'd have to store a hash of all failed passwords tried within the window of time defined.
Since there is already a counter for maximum number of failed attempts,
the
timestamp is superfluous.
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.
If the number of values in this attribute exceed the number of max fails allowed, the account is locked. Timestamp is needed to eventually expire and remove it.
Removal should only occur when a successful login occurs. There's no
need for
a separate expiration period.
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) ?...
Making security-related suggestions that you haven't fully thought
through yet
really isn't a good idea.
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).
If you only allow pwdMaxFailure attempts before locking the account,
there's
no point in even examining any passwords subsequent to the lockout
event. So
no, there should never be a need to store more than pwdMaxFailure
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.
But again, the point of this discussion is that when a legitimate user
is
trying to login, you shouldn't need to recognize more than 1 bad
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
Hi,
This thread has been dead for some time now. Here is the link to the original thread and all the follow-up discussion (http://www.openldap.org/lists/openldap-software/200901/msg00147.html). An ITS request (5911) was in place for the feature (looks like its been closed since), Howard had suggested that these requests generally get worked on as and when folks have time to implement them.
We (at Mozilla) needed this feature to better support users in-house, so we contracted the development out to Zytrax. I am happy to inform you that this code is now ready and works for us on both 2.4.13 and 2.4.16. Here is the link (http://www.zytrax.com/books/ldap/ch6/ppolicy.html) to the documentation from Zytrax about how this feature works and also contains links to download the code. I am not sure how we'd go about getting this code integrated into mainline OpenLDAP, but we would love for this code to be a part of the regular OpenLDAP releases. This code plays nice with existing setups in that its features are turned off by default and it behaves exactly as the original ppolicy module does.
Please let me know if you have any questions about how this works or if there are other concerns about including this in regular OpenLDAP software releases.
Aravind.
Aravind Gottipati wrote:
Hi,
This thread has been dead for some time now. Here is the link to the original thread and all the follow-up discussion (http://www.openldap.org/lists/openldap-software/200901/msg00147.html). An ITS request (5911) was in place for the feature (looks like its been closed since), Howard had suggested that these requests generally get worked on as and when folks have time to implement them.
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.
We (at Mozilla) needed this feature to better support users in-house, so we contracted the development out to Zytrax. I am happy to inform you that this code is now ready and works for us on both 2.4.13 and 2.4.16. Here is the link (http://www.zytrax.com/books/ldap/ch6/ppolicy.html) to the documentation from Zytrax about how this feature works and also contains links to download the code. I am not sure how we'd go about getting this code integrated into mainline OpenLDAP, but we would love for this code to be a part of the regular OpenLDAP releases. This code plays nice with existing setups in that its features are turned off by default and it behaves exactly as the original ppolicy module does.
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
Please let me know if you have any questions about how this works or if there are other concerns about including this in regular OpenLDAP software releases.
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 wrote:
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
More details are also on the X.500 list
http://www.freelists.org/post/x500standard/New-draft-on-password-policy,1
I'm all for getting useful enhancements into the published spec. But as this is a security mechanism we're talking about, it has to be designed with some care.
The scenario you've provided as motivation for the feature you describe sounds like a bunch of poorly written apps; they should immediately remove passwords from their caches the first time they fail to authenticate. At the very least, they should immediately come back to the user with an error message and ask for confirmation before retrying.
Also, using apps which perform silent implicit authentications of this sort renders parts of ppolicy useless (e.g., warnings about password expiration and/or grace logins drop on the floor instead of being presented to the user).
Fix the real problem, not just the symptom. The approach you're pushing for is just putting a bandaid on a problem, not fixing it. This may be how other folks handle their software design problems, but it just doesn't fly for security issues.
On Sun, Jul 12, 2009 at 10:53 PM, Howard Chuhyc@symas.com wrote:
Fix the real problem, not just the symptom. The approach you're pushing for is just putting a bandaid on a problem, not fixing it. This may be how other folks handle their software design problems, but it just doesn't fly for security issues.
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.
Aravind Gottipati wrote:
On Sun, Jul 12, 2009 at 10:53 PM, Howard Chuhyc@symas.com wrote:
Fix the real problem, not just the symptom. The approach you're pushing for is just putting a bandaid on a problem, not fixing it. This may be how other folks handle their software design problems, but it just doesn't fly for security issues.
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.
Regardless, your security model is broken. Further weakening the guarantees of the existing policy is only going to make it more broken, not less broken.
Think about what your actual problem is, and fix it. You haven't done any clear thinking here yet.
Your problem is that you have applications which essentially render your policy useless. There is no other word for this type of application other than "security risk." The correct solution is to mitigate that risk, not to break your policy for all the other well-behaved users. In this case, if you cannot fix the applications, then change the credentials that the apps authenticate with. Give each user an app-specific ID and password, one that is very strong and has a different expiration schedule. (Since the credential is cached in the app anyway, it doesn't matter if it's huge and inconvenient to enter, the user only has to do it once.) Limit the privileges of this app-specific credential so that it is only valid for that particular application.
The first principle of good security design is to have a clearly defined policy with no exceptions. When that fails, the second principle is to highlight all of those exceptions and define them explicitly, not hide them under the rug. Otherwise your policy is unauditable and therefore unenforceable, rendering the whole exercise pointless. Which is what we told you at the beginning of this conversation.
Aravind Gottipati wrote:
On Sun, Jul 12, 2009 at 10:53 PM, Howard Chuhyc@symas.com wrote:
Fix the real problem, not just the symptom. The approach
you're pushing for
is just putting a bandaid on a problem, not fixing it.
This may be how other
folks handle their software design problems, but it just
doesn't fly for
security issues.
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.
Regardless, your security model is broken. Further weakening the guarantees of the existing policy is only going to make it more broken, not less broken.
Think about what your actual problem is, and fix it. You haven't done any clear thinking here yet.
Your problem is that you have applications which essentially render your policy useless. There is no other word for this type of application other than "security risk." The correct solution is to mitigate that risk, not to break your policy for all the other well-behaved users. In this case, if you cannot fix the applications, then change the credentials that the apps authenticate with. Give each user an app-specific ID and password, one that is very strong and has a different expiration schedule. (Since the credential is cached in the app anyway, it doesn't matter if it's huge and inconvenient to enter, the user only has to do it once.) Limit the privileges of this app-specific credential so that it is only valid for that particular application.
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.
The first principle of good security design is to have a clearly defined policy with no exceptions.
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
Clowser, Jeff wrote:
- 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.
I don't understand the problem: If the proxy is correctly implemented it will only send exactly *one* authentication request to a user database even if there are several parallel outstanding HTTP requests to be served by the proxy. If your proxy does not serialize authentication requests and then cache authentication state then fix your proxy.
Ciao, Michael.
Clowser, Jeff wrote:
- 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.
I don't understand the problem: If the proxy is correctly implemented it will only send exactly *one* authentication request to a user database even if there are several parallel outstanding HTTP requests to be served by the proxy. If your proxy does not serialize authentication requests and then cache authentication state then fix your proxy.
The proxies cache *successful* authentication requests.
From a security POV, to suggest that "fixing" them is to cache
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
openldap-software@openldap.org
-
Aravind Gottipati -
Clowser, Jeff -
Howard Chu -
Kurt Zeilenga -
Michael Ströder -
Quanah Gibson-Mount