Bug 28980 - Add temporary passwords which must be reset after first login
Summary: Add temporary passwords which must be reset after first login
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 32219 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-09-09 04:17 UTC by David Cook
Modified: 2023-05-12 14:39 UTC (History)
8 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2021-09-09 04:17:12 UTC
It would be great if passwords could be marked as temporary, so that staff users could set temporary passwords for borrowers, and those borrowers would have to reset their password on their 1st successful login.

This would prevent staff users from re-using the same simple password across a range of users and having those same simple passwords persist over time.
Comment 1 David Cook 2021-09-09 04:17:38 UTC
I soft pitched a concept of a credential table  based off the Keycloak credential table on bug 28786 which might make this easier to implement as well...
Comment 2 Marcel de Rooy 2021-09-09 08:13:50 UTC
Would be great if you could implement this by a password expiry mechanism.
Comment 3 David Cook 2021-09-09 23:36:38 UTC
(In reply to Marcel de Rooy from comment #2)
> Would be great if you could implement this by a password expiry mechanism.

I was thinking about that a bit as well. Good call. 

I should note that I don't have any plans to work on this, but thought it was a good idea, so raised a report for it.
Comment 4 Nick Clemens (kidclamp) 2022-11-16 12:16:02 UTC
We do have a password expiry mechanism now - if a patron's password is set as expired when setup, they would have to reset on first login - but we need a convenient way of setting new passwords as expired
Comment 5 Marcel de Rooy 2022-11-16 12:20:51 UTC
(In reply to Nick Clemens from comment #4)
> We do have a password expiry mechanism now - if a patron's password is set
> as expired when setup, they would have to reset on first login - but we need
> a convenient way of setting new passwords as expired

Which is great! So it should not be that difficult anymore to make this additional step..
Comment 6 Andrew Fuerste-Henry 2022-11-16 15:43:27 UTC
Is this something we'd like defined in the patron category? So for each category one would define both the regular password expiration interval (as one does now) and, optionally, the expiration interval to use at account creation?

Our existing value is borrowers.password_expiry_days. The new value could be something like borrowers.enrollment_password_expiry_days. That name is awfully long.

That would allow one to define various setups like:

Juvenile patrons have NULL for password_expiry_days and enrollment_password_expiry_days, so their passwords never expire.

Adult patrons have password_expiry_days=365 and enrollment_password_expiry_days=0. Whatever password is set at creation is immediately expired, but going forward they expire at 365 days.

Staff accounts have password_expiry_days=365 and enrollment_password_expiry_days is NULL. Their accounts expire at 365 days with no special behavior at account creation.
Comment 7 Katrin Fischer 2022-11-16 18:42:49 UTC
If it was only to be used on patron creation, I think we would not need to store it in the borrower record. Maybe a checkbox on the patron category administration page for "enforce new password on first login" and then we realize it by setting the first expiration date to 'immediately' when this is set and the patron is created.
Comment 8 Christopher Brannon 2022-11-16 22:09:27 UTC
(In reply to Katrin Fischer from comment #7)
> If it was only to be used on patron creation, I think we would not need to
> store it in the borrower record. Maybe a checkbox on the patron category
> administration page for "enforce new password on first login" and then we
> realize it by setting the first expiration date to 'immediately' when this
> is set and the patron is created.

What would constitute recognizing it as a patron creation?

I could see this feature being used anytime staff would have to reset a password.  It might be better to have a rule set somewhere that could be enabled to force a password change whenever an account is created or the password is reset by staff.
Comment 9 Christopher Brannon 2022-11-16 22:13:31 UTC
*** Bug 32219 has been marked as a duplicate of this bug. ***
Comment 10 Katrin Fischer 2022-11-16 22:15:11 UTC
I think my use case was 'first login' for a new user. We could then implement it in the routine for adding a new patron.

But we could still do it with a button 'anytime' I think, just setting the expiration date for the password into the past.

My thought were mostly about possibly not needing a field in the borrowers table when we can look up the intended behavior for the patron category.
Comment 11 Christopher Brannon 2022-11-16 22:23:59 UTC
I'm wondering if this is necessary at all.  In rethinking another similar bug, I realize that we can set new accounts with some random, unknown password, and just rename the 'forgot password' link to something more encompassing.  Because, in theory, you could have new patrons click on that link and reset the password to something they know.  Right?
Comment 12 Andrew Fuerste-Henry 2022-11-16 22:29:01 UTC
Sorry, I misspoke a bit. I didn't mean we'd put something in the borrower, but rather the category. I said "Our existing value is borrowers.password_expiry_days. The new value could be something like borrowers.enrollment_password_expiry_days," but I really meant categories.password_expiry_days.

It might be simpler to just have a setting to do/don't automatically expire passwords created in the staff interface, but I still think that should be set in categories rather than globally in a syspref.
Comment 13 Andrew Fuerste-Henry 2022-11-16 22:31:15 UTC
(In reply to Christopher Brannon from comment #11)
> I'm wondering if this is necessary at all.  In rethinking another similar
> bug, I realize that we can set new accounts with some random, unknown
> password, and just rename the 'forgot password' link to something more
> encompassing.  Because, in theory, you could have new patrons click on that
> link and reset the password to something they know.  Right?

I've suggested this to libraries before and it works *ok,* you just tell all patrons they can't log into the OPAC until they've done a password reset. But it does require the patron to have an email address and to be comfortable with the mild complexity of the password reset process. So this could for sure get easier.
Comment 14 Katrin Fischer 2022-11-16 22:37:19 UTC
Just noting that you don't need to set any password. The password reset doesn't need an existing password. But I think there might be a use case for an initial /temporary password too. Maybe a checkbox on the password reset form in staff could be a nice idea? Could be pre-checked or not according to patron category :)
Comment 15 David Cook 2022-11-16 22:46:52 UTC
(In reply to Katrin Fischer from comment #14)
> I think there might be a use case for
> an initial /temporary password too. Maybe a checkbox on the password reset
> form in staff could be a nice idea? Could be pre-checked or not according to
> patron category :)

Sounds good to me.

Keycloak has this feature. On the "Reset Password" screen, it has the following prompts:

- Password
- Password Confirmation
- Temporary

Setting temporary passwords are handy when you need to reset someone's password for them. 

--

We'd also need this on the "Add patron" screen. A lot of libraries like to set up insecure default passwords for patrons, and it would be great to default these to be "Temporary". This is where having an option at the patron category level would be useful. 

--

Other than that... it could be good for the "Import patrons" tool to take a "temporary_password" option as well, so that imported patrons need to reset their passwords after first login too.
Comment 16 Christopher Brannon 2022-11-16 23:00:35 UTC
So, maybe we direct first time users to the link (reworded or not) and they set their password.

For patrons that don't have an e-mail, we have a set/reset option that generates a temporary password, and prints a slip that directs them to a page where they type in their library card number (not printed on the slip), and they use that password.  Then it prompts them to reset the password.  The slip doesn't have to be printed for over-the-phone resets.  We just direct them to the page and give them the password over the phone.
Comment 17 David Cook 2022-11-16 23:54:01 UTC
(In reply to Christopher Brannon from comment #16)
> So, maybe we direct first time users to the link (reworded or not) and they
> set their password.
> 
> For patrons that don't have an e-mail, we have a set/reset option that
> generates a temporary password, and prints a slip that directs them to a
> page where they type in their library card number (not printed on the slip),
> and they use that password.  Then it prompts them to reset the password. 
> The slip doesn't have to be printed for over-the-phone resets.  We just
> direct them to the page and give them the password over the phone.

With other systems in a public library context, usually a new user will be told "your password is the last 4 digits of your phone number" or something like that, and then when you log into the OPAC with that password, it prompts you to reset your password.
Comment 18 Katrin Fischer 2022-11-16 23:59:28 UTC
(In reply to David Cook from comment #17)
> (In reply to Christopher Brannon from comment #16)
> > So, maybe we direct first time users to the link (reworded or not) and they
> > set their password.
> > 
> > For patrons that don't have an e-mail, we have a set/reset option that
> > generates a temporary password, and prints a slip that directs them to a
> > page where they type in their library card number (not printed on the slip),
> > and they use that password.  Then it prompts them to reset the password. 
> > The slip doesn't have to be printed for over-the-phone resets.  We just
> > direct them to the page and give them the password over the phone.
> 
> With other systems in a public library context, usually a new user will be
> told "your password is the last 4 digits of your phone number" or something
> like that, and then when you log into the OPAC with that password, it
> prompts you to reset your password.

This doesn't feel like a good practice because it would encourage insecure passwords and there is no guarantee the user will log in and change it anytime soon?
Comment 19 David Cook 2022-11-17 00:05:13 UTC
(In reply to Katrin Fischer from comment #18)
> This doesn't feel like a good practice because it would encourage insecure
> passwords and there is no guarantee the user will log in and change it
> anytime soon?

Koha already gives libraries the ability to do this anyway, so the "temporary password" option would at least add a layer of protection over top of their existing insecure practice.

(I've actually been thinking more lately about implementing system restrictions so that even superlibrarians can't create insecure Koha configurations.)
Comment 20 Christopher Brannon 2023-05-12 14:39:16 UTC
I agree with an earlier statement, that this should be only applied to accounts created by staff.  If you are letting patrons create their own password on patron self registration, it should not be needed.

That said, to fall in line with existing password settings, there should be a default general setting to force first time users created by staff to reset the password.  This setting should also exist at the patron category level.

It should apply to memberentry.pl?op=add, and be ignored with memberentry.pl?op=edit.