ppolicy: pardon password history

[h***@hrz.uni-marburg.de]

Hi list,

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.

Best regards,
Florian

[Michael Ströder]

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]

Content preview: On Mon, Apr 20, 2015 at 07:28:31PM +0200, Michael Ströder
wrote: > ***@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. [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[194.106.223.201 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
Cc: ***@hrz.uni-marburg.de, openldap-***@openldap.org
X-BeenThere: openldap-***@openldap.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OpenLDAP development discussion list <openldap-devel.openldap.org>
List-Unsubscribe: <http://www.openldap.org/lists/mm/options/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=unsubscribe>
List-Archive: <http://www.openldap.org/lists/openldap-devel/>
List-Post: <mailto:openldap-***@openldap.org>
List-Help: <mailto:openldap-devel-***@openldap.org?subject=help>
List-Subscribe: <http://www.openldap.org/lists/mm/listinfo/openldap-devel>,
<mailto:openldap-devel-***@openldap.org?subject=subscribe>
Errors-To: openldap-devel-***@openldap.org
Sender: "openldap-devel" <openldap-devel-***@openldap.org>
X-Spam-Score: -4.2 (----)
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: On Mon, Apr 20, 2015 at 07:28:31PM +0200, Michael Ströder
wrote: > ***@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. [...]

Content analysis details: (-4.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[194.106.223.201 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]

Post by Michael Ströder

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. 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.

Andrew

[Michael Ströder]

Post by Andrew Findlay

Post by Michael Ströder

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.

Post by Andrew Findlay
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.