Bug 32369

Summary: Two factor authentication can be bypassed if catalog and staff interface URL aren't properly configured
Product: Koha Reporter: Chris Slone <cslone>
Component: AuthenticationAssignee: Bugs List <koha-bugs>
Status: CLOSED WONTFIX QA Contact: Testopia <testopia>
Severity: minor    
Priority: P5 - low CC: dcook, dpavlin, jonathan.druart, m.de.rooy
Version: 22.05   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32385
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:

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.