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.
Thanks Jeffrey Crawford
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.
openldap-technical@openldap.org
-
Howard Chu -
Jeffrey Crawford