Bug 20476 - Two factor authentication for the staff client - omnibus
Summary: Two factor authentication for the staff client - omnibus
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Staff interface (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
Depends on: 14319 19886 28787 29835 19887 28786 29894 30588 31240 31247
Blocks: 33253 33254
  Show dependency treegraph
Reported: 2018-03-26 17:41 UTC by Magnus Enger
Modified: 2023-03-16 16:55 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Note You need to log in before you can comment on or make changes to this bug.
Description Magnus Enger 2018-03-26 17:41:02 UTC

Comment 1 Magnus Enger 2018-03-26 17:43:01 UTC
Optional two factor authentication for the staff client would be A Very Good Thing, especially in light of GDPR in Europe.
Comment 2 Magnus Enger 2018-03-26 17:47:08 UTC
There are plenty of ways to implement 2FA I guess (see the "Depends on" for this bug), so getting a system in place that could easily be extended with plugins would be super awesome.
Comment 3 Jon Knight 2018-03-26 18:32:34 UTC
Is there an issue with using a pre-existing tool such as PrivacyIDEA (https://github.com/privacyidea/privacyidea) that already does 2FA (in lots of different forms)? Does it really need to be rolled into the Koha code base, rather than allowing sysadmins to use external 2FA support? They might need to do anyway if their Koha installation is just one small service in a much larger organisation that already uses 2FA, so if it was bolted inside Koha it would need to be done in a way that could be turned off if external 2FA services were being used.

Just for completeness I should mention that we've tested PrivacyIDEA 2FA with YubiKeys tied into SAML2.0 authentication using simpleSAMLphp as the IdP and it works OK. Not deployed in production yet as someone would have to come up with a budget for all the Yubikeys we'd need!
Comment 4 Magnus Enger 2018-03-28 22:59:08 UTC
I am not a 2FA expert, so whatever works is fine by me. Does implementing support for external 2FA mean we can not implement internal 2FA? If not, I think we should be open to both solutions.
Comment 5 George Williams (NEKLS) 2018-05-17 15:40:44 UTC
So long as the two factor authentication is optional, I think this is a great idea.
Comment 6 Sam S 2023-03-14 16:15:30 UTC
I've been testing the module in our install, working great so far, but I noticed a few issues, both minor:

1. The authentication form field is not marked to be excluded from auto completion. Because of this, after several weeks of use, every time I click on the field, I see a list of all prior authentication codes used. This might be possible to be used in an attack to reverse-engineer the secret key using past codes and when they were entered. Information on how to disable auto completionon form fields can be found here:

2. There's currently no option to "trust current device" something that most MFA modules include, so a user can mark a local device to be excluded from the MFA check for an amount of time (typically a month or so)
Comment 7 Katrin Fischer 2023-03-15 22:16:16 UTC
(In reply to Sam S from comment #6)
> I've been testing the module in our install, working great so far, but I
> noticed a few issues, both minor:

Hi Sam, thanks for your suggestions, would you mind filing them as separate bug reports linked to this one? You can use the "Blocks" in the new bugs or the "Depends on" in this one to link them.