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