Bug 20476

Summary: Two factor authentication for the staff client - omnibus
Product: Koha Reporter: Magnus Enger <magnus>
Component: Staff interfaceAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: george, gmcharlt, hanna.dehlin, J.P.Knight, jzairo, kelly, m.de.rooy, martin.renvoize, sally.healey, tech.sam
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14319
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 19886, 29835, 14319, 19887, 28786, 28787, 29894, 30588, 31240, 31247    
Bug Blocks: 33254, 33253    

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:
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

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.