require users update old passwords

[Llewellyn Marshall]

Evergreen 3.7.2

NC Cardinal is developing patches to increase the security of our staff accounts by enforcing new password policies. One of these new policies is for users to update their password every 90 days. Our current implementation doesn’t prohibit users from accessing their accounts, but it will bug them with alerts on their splash screen, alerts on the myopac main page, a message on the patron edit screen below the password field, and an email notice.

This reminder is configurable by a new org unit setting: 'global.password_reset_age'. This setting is the maximum number of days before a user will be notified about needing to update their password from the staff client. If this setting is unset or less than 1, no alerts will be displayed.

For display in the OPAC we’ve created a new config setting: ctx.password_age_reminder. By default, this setting is equal to 'global.password_reset_age'. If this setting is less than 1, no alerts will be displayed.

For the email notices, we’ve created a new hook, validator, and example event definition. The new hook, au.passwd_changed, fires off whenever a user’s password is updated. This can come from the staff client, myopac, or password reset form. The validator, PatronOldPassword, checks to see whether the user has updated their password in the interval between when the event is processed and the time it was created. Events will be marked as “invalid” if the user has already updated their password.

Under the hood, a user’s password create and edit dates are available through a new field mapped class: actor::usr_password_set_date. This virtual table exposes the user, create_date and edit date from actor.passwd. This information is retrieved via a new API call “open-ils.actor.get_password_age”. This API call will return the number of days since the password was last updated.

I'll post a link to our patch below.

[Llewellyn Marshall (lbmarshallv)]

link to patch on working repository:
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/lew/lp-1979570-detect-password-age

[Jason Boyer (jboyer)]

There are certainly things that we could do to improve password security but I'm going to argue against time-based forced password changes (And NIST agrees: https://pages.nist.gov/800-63-3/sp800-63b.html#-5112-memorized-secret-verifiers paragraph 9). It encourages staff to pick a password they can remember that meets the requirements and then just make minimal changes to shut the up algorithm each quarter ('bad1', 'bad2', 'bad3', etc.).

A better solution is to increase the minimum size and encourage staff to use a password manager so they can start using *really* secure passwords that they could never hope to remember at all.

I also initially read this as applying only to staff, but I'm absolutely certain that imposing this on patrons will make many of their accounts more secure as they simply stop using their accounts entirely. Most *banks* don't do this to the general public.

[Galen Charlton (gmc)]

Llewellyn, is there a specific regulation, compliance regime, or insurance requirement that NC Cardinal must adhere to that's motivating a need for mandatory password aging?

[Rogan Hamby (rogan-hamby)]

One thing I would be curious to have handy in this discussion is feedback from community institutions about their external requirements (from governing bodies, local regulations, etc..) and wishlists for password security. I'm all for more security but do worry this could turn into Whack-A-Mole as institutions go "but we have to do X".

[Jason Stephenson (jstephenson)]

While I agree with NIST on not changing passwords, and did so before they came to that conclusion, I am not opposed to the addition of such a feature so long as it is a) off by default and b) is enabled via YAOUS or internal flag. It might be useful to have separate settings for staff vs. patrons.

[Llewellyn Marshall (lbmarshallv)]

NCDIT has a policy where state and local government employees must change their NCID passwords every 90 days. At a meeting of our NC Cardinal governance committee, we voted to adopt a similar policy for our instance of Evergreen. We also voted to increase the minimum strength requirements for passwords as well, but the committee wished to have different requirements based on permission group so that patrons would be allowed to have simpler passwords than circulators and admin. We will tackle this in the next phase of our patron password policy project.

By default, there are no notices or alerts until the global.password_reset_age org setting has a positive value. The only change visible without this is that the age of the password is visible beneath the password field on the patron edit screen.

[Jason Boyer (jboyer)]

Edit: It took me so long to write this up that I didn't see Llewellyn's reply above, so that's why it looks like I didn't read it. :)

I have more thoughts after giving this more time than a quick comment before I leave for the day. Still not a fan of the idea but as others have pointed out that's no help if you're perhaps forced to implement it by external entity.

There are some changes that would likely be needed for this:

There should probably be a flag added to permission.grp_tree entries that controls whether or not this feature applies to a particular user profile even if an org has enabled it. One instance that springs to mind where this should not be enabled is service accounts for things like SIP, NCIP, etc. For instance, when using NCIP service accounts for inter-library loaning it's possible that these notices would be sent to remote staff users who aren't able to act on them, causing only a nuisance.
While this currently has no "teeth" a feature like this can only really be effective when users with "expired" passwords are no longer able to login and there needs to be a way to prevent that for some types of accounts.

Since you've added the IDL entry for the view on actor.passwd I believe the a/t event generation can be handled with a passive event rather than active (similar to how checkout.due works for notices) which would make the hook changes in Actor.pm and the Validator.pm addition unnecessary.

I'm not sure if adding the open-ils.actor.get_password_age api call is the most direct way to go about this. There may be a way for the open-ils.auth.complete or .login methods to somehow include the time remaining before a password expires. In that case the ui need only check for this indicator and show a notice based on that rather than having to check the password age and compare against the OUS, etc. (Others more familiar with the inner workings of auth may also say that's not possible in which case, bummer.)

Some minor things:

Most of the changes in opac templates should probably be moved into EGCatLoader.pm, a function called from it, misc_util.tt2, or an OUS, especially the config.tt2 changes.

For the sample notice it would be best to replace the password age in the message body with either the actual value pulled via helper or simply be a more generic message.

The coust entry should probably be in the 'sec' group and be named 'auth.password_expire_age or something like that.

Thank you for including a live test.

[Llewellyn Marshall (lbmarshallv)]

I've worked through a lot of the changes suggested above along with one our clients had. Changes have been squashed into my commit on https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/lew/lp-1979570-detect-password-age

1. Made my password updated hook into a passive one on my new FM_IDL class. This uses the user's Home OU as the context org.

2. Updated the event to use the passive hook & deleted the validator

3. renamed the library setting to auth.password_expire_age and put it in the sec group

4. a client noticed you could get around the message by re-entering your password into the OPAC's password change screen. I've changed it so it will prevent you from updating your password using your current password.

I'm hesitant to get rid of the config.tt2 changes or modify the permission groups. In phase 2 of our project, we're tossing around the idea of creating a "password policy" object that would contain the password regex and other requirements such as the expiration age. These policies would be mapped to a permission group and org unit.

[Katie Greenleaf Martin (kgmspark)]

I like that this makes (staff) users more cognizant of security -- while having permission-group-specific regex requirements for accounts would also be wonderful, this uses existing database functionality and interfaces to add some additional security. We would be interested in this for staff accounts, but not for patron accounts.

[Kathy Lussier (klussier)]

I'm posting a link to the relevant bug - https://bugs.launchpad.net/evergreen/+bug/1013786. It doesn't sound like this code will address the feature requested there. That bug was seeking the restoration of a feature we used to have in the jspac days that checked for password strength when logging into the catalog, but didn't check for the strength when setting it in the patron editor. It supports a use case where the staff sets a fairly simple password when registering a patron and then forces them to strengthen it when they log into the catalog the first time.

When it comes to patron passwords, the goal should be to remove library staff from this process as much as possible. Password setting should be between the patron and the system. For that reason, I'm curious about the choice to include the message in the patron edit screen. This message will encourage staff to ask patrons what they would like to use for a new password, when we should really be encouraging patrons to set it themselves.

Thanks for getting started on this code Llewelyn! I'm looking forward to any improvements to password security in Evergreen!