Aravind Gottipati wrote:
On Sun, Jul 12, 2009 at 10:53 PM, Howard Chu<hyc@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.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/