[Bug 32369] New: Two Factor Authentication Can Be Bypassed If Catalog and Staff Client URL Aren't Properly Configured
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32369 Bug ID: 32369 Summary: Two Factor Authentication Can Be Bypassed If Catalog and Staff Client URL Aren't Properly Configured Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Authentication Assignee: koha-bugs@lists.koha-community.org Reporter: cslone@camdencountylibrary.org QA Contact: testopia@bugs.koha-community.org CC: dpavlin@rot13.org 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. -- 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=32369 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com Summary|Two Factor Authentication |Two factor authentication |Can Be Bypassed If Catalog |can be bypassed if catalog |and Staff Client URL Aren't |and staff interface URL |Properly Configured |aren't properly configured -- 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=32369 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #1 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Not sure this is considered a bug. It's a configuration issue in my opinion. -- 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=32369 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #2 from David Cook <dcook@prosentient.com.au> --- (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. -- 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=32369 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #3 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- 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. -- 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=32369 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=32385 -- 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=32369 --- Comment #4 from Chris Slone <cslone@camdencountylibrary.org> --- Fair enough, just wanted make sure it was known if it wasn't already. Sounds good on the new bug about the session cookies. -- 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