[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Password Policy pwdFailureTime count limits?

Jeffrey Crawford wrote:
Hello Everyone,

I'm having trouble enforcing our password policy for login attempts
within a particular time frame. After looking into the issue a little
further it seems to stem from the fact that the operational attribute
pwdFailureTime can only resolve time down to the second. so if there
are three Bind attempts within a single second we only get a single
pwdFailureTime entry for that time. Our policy is geared more to try
and prevent brute force attacks since this instance of the ldap server
will be available publicly. However someone can continuously try to
bind and not lock the account for as many seconds as is defined in the
pwdMaxFailure attribute in the policy definition.

For example:
if the following account locking configs are set
pwdMaxFailure: 10
pwdFailureCountInterval: 3600
pwdLockout: TRUE
pwdLockoutDuration: 30

If I try to lock my account by providing the incorrect credentials 11
times, it didn't lock if my 11 attempts were shorter than 10 seconds,
I then tried 100 in a for loop which finished in 7 seconds, it still
didn't lock. I looked at the account and counted the number of
pwdFailureTime's and found 7. I then place a one second sleep between
each bad bind attempt and low an behold it would lock as expected.
Therefore there seems to be a limitation of pwdFailureTime to only
resolve down to the second and its inability to store the same time
multiple times.

I'm not sure if this is expected behavior, but it makes locking
policies against brute force attacks more difficult to fend against. I
did a quick look to see if there was a way of delaying a incorrect
credential bind so it wouldn't return for at least a second, but
didn't see one. If such a config exists it might help if someone can
point me to it.

A delay option is in the latest Draft specification, but not implemented by anyone (as far as I know). Yes, it seems we should be using finer than 1-second resolution for the failure timestamps. Might be worth filing an enhancement request for this in the ITS.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/