Able to login to staff client with old card number

Bug #1844121 reported by Dawn Dale
274
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Unassigned
3.6
Fix Released
High
Unassigned

Bug Description

We recently discovered that staff are able to use an old card number to log into the staff client. We see this as a security problem.

Example, Mrs. Jones is a library manager and works at library A. Mrs. Jones misplaces her library card and needs to get a new one. Her card is replaced. Out of habit she logs into EG with her old card number and pin and is successful. Realizing her mistake she logs out and uses her new card number. However, if her card is found by someone, they could log into EG using her card. I realize this is not very likely but it is still a security problem.

Thanks,

Dawn Dale (ddale)
tags: added: circulation
information type: Public → Private Security
information type: Private Security → Public Security
Revision history for this message
Eva Cerninakova (ece) wrote :

Confirmed in Evergreen 3.3.2
I made sure that the old card haven't been checked as active, but even so, I was able to use the card number to log in.

Changed in evergreen:
status: New → Confirmed
Changed in evergreen:
importance: Undecided → High
Revision history for this message
Galen Charlton (gmc) wrote :

Noting that is an issue specifically with the AngularJS client, which still uses open-ils.auth.authenticate.init + open-ils.auth.authenticate.complete. It is not an issue with the Angular client, which uses open-ils.auth.login and will reject the login with a PATRON_CARD_INACTIVE event.

Revision history for this message
Galen Charlton (gmc) wrote :

Some approaches I see for fixing this:

- Switch the AngularJS client to using open-ils.auth.login. This won't fix it for any remaining XUL users.
- Make open-ils.auth.authenticate.init, when asked to retrieve a user by barcode, restrict the lookup to active cards. Doing this will short-circuit a subsequent authenticate.complete call. This would apply to the OPAC, however, so are there any circumstances where we would want a patron to be able to log into the OPAC using an inactive card? I assume not, but want to confirm.

Revision history for this message
Terran McCanna (tmccanna) wrote :

By "inactive" do you mean that it's not the current library card on the account, or that the account itself is inactive?

Revision history for this message
Galen Charlton (gmc) wrote :

Mostly immediately, that the card itself is inactive, but that could apply to inactive users.

Revision history for this message
Terran McCanna (tmccanna) wrote :

Thanks for the clarification. We would still want inactive users to be able to log in to the OPAC so that they can pay old bills, see what books are still lost on their account, etc. (We can hope, anyway.)

However, we only want them to be able to log in with the barcode that is marked as their current barcode, not with any earlier barcodes they might have had.

Revision history for this message
Galen Charlton (gmc) wrote :

A patch is available at

user/gmcharlt/lp1844121_prevent_staff_login_by_inactive_barcode / https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/gmcharlt/lp1844121_prevent_staff_login_by_inactive_barcode

Testers should note that, like anything that touches the auth code, there could be gremlins that I did not turn up.

Changed in evergreen:
milestone: none → 3.7.2
tags: added: authentication pullrequest
removed: circulation
Revision history for this message
Galen Charlton (gmc) wrote :

Terran, re your comment #6, Evergreen has prevented inactive patrons from logging into the OPAC for years, but with a very specific definition of "inactive": patrons where the active flag is off. It does let patrons whose expiration date is in the past continue to log in.

Revision history for this message
Shula Link (slink-g) wrote :
tags: added: signedoff
Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Revision history for this message
Mike Rylander (mrylander) wrote :

Thanks, all. Pushed to master, 3.7, and 3.6.

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Mike Rylander (mrylander) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.