First of all, password lockout itself is a dumb idea, and we only implement it because it's part of the original ppolicy spec. The ppolicy spec is pathetically bad though.
What methods aren't dumb ideas that accomplish account unavailability on N password failures?
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Chris Jacobs wrote:
First of all, password lockout itself is a dumb idea, and we only implement it because it's part of the original ppolicy spec. The ppolicy spec is pathetically bad though.
What methods aren't dumb ideas that accomplish account unavailability on N password failures?
Look at a later rev of the spec - use increasing delays. It's the standard approach used by Unix for 40-some years.
Chris Jacobs wrote:
First of all, password lockout itself is a dumb idea, and we only implement it because it's part of the original ppolicy spec. The ppolicy spec is pathetically bad though.
What methods aren't dumb ideas that accomplish account unavailability on
N password failures?
Look at a later rev of the spec - use increasing delays. It's the standard approach used by Unix for 40-some years.
Is that implementable in OpenLDAP or is this on a per client basis? If client, for all practical purposes that's not exactly 'doable', forcing us back to the auth source - OpenLDAP. Think of configuring pfSense, F5 BigIP, httpd, pam, etc. Some certainly are configurable for that, but the how at first google search pass seems to be wide and varied.
FWIW: I'd love to get out of the 'can you unlock my account' business, and this to be implementable via OpenLDAP, although I kind of doubt it is; (it might communicate the command to delay - clients would have to understand so back to client ability dependency, or it might just delay a response to the client - which seems like a bad idea).
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Chris Jacobs wrote:
Chris Jacobs wrote:
First of all, password lockout itself is a dumb idea, and we only implement it because it's part of the original ppolicy spec. The ppolicy spec is pathetically bad though.
What methods aren't dumb ideas that accomplish account unavailability on
N password failures?
Look at a later rev of the spec - use increasing delays. It's the standard approach used by Unix for 40-some years.
Is that implementable in OpenLDAP or is this on a per client basis? If client, for all practical purposes that's not exactly 'doable', forcing us back to the auth source - OpenLDAP. Think of configuring pfSense, F5 BigIP, httpd, pam, etc. Some certainly are configurable for that, but the how at first google search pass seems to be wide and varied.
Think. Clearly it must be implemented in the LDAP server, since actual attackers will not use delays in their attack code.
openldap-technical@openldap.org
-
Chris Jacobs -
Howard Chu