9:16 a.m.
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.
9:47 a.m.
New subject: pplolicy lockout grace time? - alternatives
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10:33 a.m.
New subject: pplolicy lockout grace time? - alternatives
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.
11:10 a.m.
New subject: pplolicy lockout grace time? - alternatives
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
3420
days inactive
3420
days old
openldap-technical@openldap.org
3 comments
2 participants
participants (2)
-
Chris Jacobs -
Howard Chu