Password Requirements Overhaul

[Llewellyn Marshall]

Evergreen 3.11

Relevant Launchpad Bugs:

My original Password Project bug
https://bugs.launchpad.net/evergreen/+bug/1979570

Check for password strength at login
https://bugs.launchpad.net/evergreen/+bug/1013786

In the first phase of the NC Cardinal password project, we introduced a new feature that records and displays how old a user’s password is. A library setting was used to define how old a staff member’s password could be before a message would be displayed on the splash screen indicating that they had ought to update their password.

In Phase 2, Blake and I have expanded upon this idea by creating “password policies” that define different password rules for users based on their home library and permission groups. Policies are inherited via ancestors so finer grain rules can be created for specific groups and/or at a branch level.

Password policies contain the following rules:

+ How long a user’s password is valid for
+ At what time the splash-screen warning message should be displayed
+ Password regular expression
+ (for staff) whether a password reset is required
+ Password hint that is displayed anywhere that a password can be changed.

The default password policy mirrors what is already established by the global.password_regex YAOUS: All users are required to have a password that is at least 4 characters long.

Any staff member is now able to change their own password through the staff client. Required password resets work the same as registering a new workstation. Staff login to the client like normal, but are rerouted to the new password reset page until they’ve updated their password. Staff are required to login using their new password after it has been successfully updated.

One thing we needed to be wary of was finding ourselves in a scenario where a user had the permissions of an admin but the password requirements of a patron. Because users may belong to more than one permission group, it was necessary to create a way to determine which password policy should be used given a list of potential policies. Blake created a function which determines the strength of the policy’s regular expression given a series of “test passwords” to compare against it. The policy with the least permissive regular expression is chosen as the favored policy for the user.

Lastly, one of the few parts carried over verbatim from phase 1 is the password reset email notice. This works off of a hook called aupsd.passwd_changed that fires off when a user’s password has changed. The validator PatronOldPassword ensures that the patron has not changed their password in the time since this event was created.

Our branch:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/blake/password_policy_3_11