[Date Prev][Date Next]
Re: password policy - alternate lockout mechanism
Aravind Gottipati wrote:
On Sun, Jul 12, 2009 at 10:53 PM, Howard Chu<firstname.lastname@example.org> 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
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/