[Bug 28980] New: Add temporary passwords which must be reset after first login
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Bug ID: 28980 Summary: Add temporary passwords which must be reset after first login Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs@lists.koha-community.org Reporter: dcook@prosentient.com.au QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- 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... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #2 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Would be great if you could implement this by a password expiry mechanism. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=32219 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Nick Clemens <nick@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick@bywatersolutions.com --- Comment #4 from Nick Clemens <nick@bywatersolutions.com> --- 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 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (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.. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Andrew Fuerste-Henry <andrewfh@dubcolib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrewfh@dubcolib.org --- Comment #6 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #7 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #8 from Christopher Brannon <cbrannon@cdalibrary.org> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #9 from Christopher Brannon <cbrannon@cdalibrary.org> --- *** Bug 32219 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #10 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #11 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #12 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #13 from Andrew Fuerste-Henry <andrewfh@dubcolib.org> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #14 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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 :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #16 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #18 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (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? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (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.) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Jason Robb <jrobb@sekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jrobb@sekls.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=33462 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 --- Comment #20 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28980 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #21 from David Cook <dcook@prosentient.com.au> --- I think that we can probably mark this as a duplicate of bug 33462 *** This bug has been marked as a duplicate of bug 33462 *** -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org