Re: password policy - alternate lockout mechanism

Aravind Gottipati wrote: 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/