hercherf@hrz.uni-marburg.de wrote:

I have made a tiny modification to the ppolicy-module. The aim is to go easy on people who forgot their password, or forgot to deploy their recently changed password to all devices (think of laptops, smartphones, etc.). Whenever a login fails due to a invalid password, the ppolicy-module will count this as a failure. After a configurable number of password failures in a given time, ppolicy will take action and - for example - lock the acount. I have tried to tweak this behaviour: When the password is found in the password history, the ppolicy-module will not count this as a password failure. If anyone is interested in this, please find the attached patch which also includes a working example configuration/testcase.

I guess this change would open a can of worms, e.g. when password expiry is in effect.

Ciao, Michael.

Andrew Findlay wrote:

On Mon, Apr 20, 2015 at 07:28:31PM +0200, Michael Ströder wrote:

...

hercherf@hrz.uni-marburg.de wrote:

...

Whenever a login fails due to a invalid password, the ppolicy-module will count this as a failure. After a configurable number of password failures in a given time, ppolicy will take action and - for example - lock the acount. I have tried to tweak this behaviour: When the password is found in the password history, the ppolicy-module will not count this as a password failure. If anyone is interested in this, please find the attached patch which also includes a working example configuration/testcase.

I guess this change would open a can of worms, e.g. when password expiry is in effect.

Should be OK: it is not allowing authentication with an old password, just not counting it against the lockout criteria.

You're right that when the current password is expired also all passwords in the password history cannot be used for a bind.

But think of the reason for password expiry: It's used to effectively forbid the use of an old password for binding. The reason is that old passwords might have been compromised without the user or admin taking notice of the compromise.

So if the current password is valid, because pwdChangedTime is new enough, all old passwords can still be used for binding. That renders password expiry ineffective.

'pwdHistory' also contains the password change timestamp for each password hash. So slapo-ppolicy's password expiry check would have to take this timestamp into account instead of 'pwdChangedTime' attribute.

This would not help with usability when the former password was already expired and a new password was set *afterwards*. In this situation the user will run into lockout anyway.

If one *has* to have password lockout then I think something like this is essential to reduce the risk of denial-of-service to legitimate users.

When using automatic password lockout one has to carefully choose the lockout parameters anyway to avoid adding a big DoS attack vector. But IMO that's something completely different.

Before anything is changed in slapo-ppolicy we have to carefully discuss the corner-cases.

(This reminds me of one long-running ietf-ldapext work-item: Getting password policy draft in good shape…)

Ciao, Michael.