Bug 32369 - Two factor authentication can be bypassed if catalog and staff interface URL aren't properly configured
Summary: Two factor authentication can be bypassed if catalog and staff interface URL ...
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: 22.05
Hardware: All All
: P5 - low minor (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-29 17:26 UTC by Chris Slone
Modified: 2023-12-28 20:42 UTC (History)
4 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 Chris Slone 2022-11-29 17:26:21 UTC
Ideally, there aren't any publicly accessible, production sites set up in the way described below, however there is a bypass of 2FA if there are (though this would still require a compromised PIN).

I have a test environment of Koha on a local-network server. When I first set it up, I made the staff client address the IP of the server, and the OPAC the same IP at a specific port (xxx.xxx.xxx.xxx:8081). I've never gotten around to correcting that, and consequently when I'm logged into the staff client it also considers me to be logged in to the OPAC, and visa versa (at that point I can go to either the IP or the IP+Port to go between them).

I set up two factor authentication on a staff account, which is working correctly when I log into the staff client. As expected, when I log into the OPAC there's no 2FA code requested, however I can then just go to the base IP (the staff client) and I will be logged into the staff client without having to deal with 2FA.
Comment 1 Jonathan Druart 2022-11-30 10:59:06 UTC
Not sure this is considered a bug. It's a configuration issue in my opinion.
Comment 2 David Cook 2022-11-30 23:19:10 UTC
(In reply to Jonathan Druart from comment #1)
> Not sure this is considered a bug. It's a configuration issue in my opinion.

I'm inclined to say the same.
Comment 3 Marcel de Rooy 2022-12-01 07:28:50 UTC
No, this is not a bug. This is design :) It always worked that way already. If you log in via the OPAC, you have a session (+cookie) that allows you access to staff too [when having sufficient permissions] when sharing the same domain between OPAC and staff. So, 2FA works here as expected.

If you do not want that to happen, it is indeed a matter of configuration. Make sure that OPAC and staff are not using the same domain. They wont share the cookie, problem solved.

Thats not the final word imo though. We already have reports asking for e.g. separate timeout settings for OPAC and staff/intranet sessions. We should imo create a separate OPAC and staff session and session cookie. This probably wont happen before refactoring/rewriting C4::Auth?
I couldnt find a report for separating the session so quickly, so I opened a new one. But I think that it must have been submitted already in the past, only with some other terms or so..

Bug 32385. Closing this one.
Comment 4 Chris Slone 2022-12-01 14:10:46 UTC
Fair enough, just wanted make sure it was known if it wasn't already. Sounds good on the new bug about the session cookies.