Bug 19886 - Two Factor Authentication: Yubikey
Summary: Two Factor Authentication: Yubikey
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 20476
  Show dependency treegraph
 
Reported: 2017-12-27 22:32 UTC by Michal Denar
Modified: 2022-04-22 09:23 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:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Denar 2017-12-27 22:32:08 UTC
We need to add support for  Two Factor Authentication, because password isn't enough against hackers or unathorised acess.

Yubikey is USB hardware
    FIDO U2F
    Secure Static Passwords
    smart card (PIV)
    Yubico OTP
    Code Signing
    OpenPGP
    OATH-TOTP
    OATH-HOTP
    Challenge-Response

https://www.yubico.com/product/yubikey-4-series/

Yubikey Perl support
https://developers.yubico.com/yubico-perl-client/
Comment 1 Jon Knight 2018-01-02 11:54:21 UTC
Is this something that needs to be built into Koha, or is it better to make use of existing third party systems such as PrivacyIDEA (https://www.privacyidea.org/) that can be used in conjuction with normal SSO mechanisms?  For example we (Loughborough University) have tested Yubikeys with PrivacyIDEA and simpleSAMLphp IdP and it works, and we already know that Koha can use the SAML2.0 authentication assertions from the IdP (as that's what we're doing in production with PTFS-E).  PrivacyIDEA also can also support Google Authentication as suggested in Bug 19887.
Comment 2 Michal Denar 2018-11-16 10:21:18 UTC
Hi,
here some useful informations for implementing U2F in Perl
http://blogs.perl.org/users/mschout/2018/01/testing-fidou2f-two-factor-authentication.html
Comment 3 Ray Delahunty 2019-11-26 15:09:03 UTC
Koha needs additional layers of authentication. With the spread of equipment such as Amazon-locker type units to hold (often expensive) items obtained for interlibrary loan, and kit such as laptop loan units, there is the danger of unauthorised use via SIP2. Sites using RFID user cards with the cardnumber embedded on them are vulnerable to stock loss if a user card is lost and then found and used maliciously. Adding PIN functionality (for example) would reduce this risk.
Comment 4 David Cook 2019-11-27 01:38:33 UTC
(In reply to Jon Knight from comment #1)
> Is this something that needs to be built into Koha, or is it better to make
> use of existing third party systems such as PrivacyIDEA
> (https://www.privacyidea.org/) that can be used in conjuction with normal
> SSO mechanisms?  For example we (Loughborough University) have tested
> Yubikeys with PrivacyIDEA and simpleSAMLphp IdP and it works, and we already
> know that Koha can use the SAML2.0 authentication assertions from the IdP
> (as that's what we're doing in production with PTFS-E).  PrivacyIDEA also
> can also support Google Authentication as suggested in Bug 19887.

I wonder about this as well. I'm fond of Keycloak for this purpose. It can use SAML or OpenID Connect. I have a local OpenID Connect client I wrote for Koha, and I've thought about using Keycloak in the test plan for when I finish the patches for Bugzilla...

That said, adding support to Koha would make it easy for people to have more secure out of the box implementations without needing more third party software.
Comment 5 David Cook 2019-11-27 01:41:59 UTC
(In reply to Ray Delahunty from comment #3)
> Koha needs additional layers of authentication. With the spread of equipment
> such as Amazon-locker type units to hold (often expensive) items obtained
> for interlibrary loan, and kit such as laptop loan units, there is the
> danger of unauthorised use via SIP2. Sites using RFID user cards with the
> cardnumber embedded on them are vulnerable to stock loss if a user card is
> lost and then found and used maliciously. Adding PIN functionality (for
> example) would reduce this risk.

Additional layers of authentication could be used for Staff Client login or OPAC login, but I don't think the layers you describe are very realistic for most libraries (ie I worked on the front lines of libraries for years and getting patrons to remember a number or a card is hard enough in itself). I also think they're a different use case than what is being described in this bug report. But an interesting idea.
Comment 6 David Cook 2020-05-03 23:42:43 UTC
I'd be open to testing work to add support for Yubikey to Staff Client auth.
Comment 7 Aaron Sakovich 2020-05-27 16:26:44 UTC
The FIDO alliance has published a new website promoting FIDO2 for both consumers and providers. FIDO2 includes Yubikey and other key vendor support, as well as biometrics (facial scans and fingerprint), and personal PINs.

https://loginwithfido.com/provider/

This is an established and well-supported standard, defined by both the FIDO Alliance and W3C's webauthn. Just dropping this here as I think it might be a better, all-encompassing approach to authentication in general, beyond just adding 2FA, and is way easier for the end-user with its multiple supported authenticators, not just a single vendor's hardware key.
Comment 8 David Cook 2020-05-27 23:26:40 UTC
(In reply to Aaron Sakovich from comment #7)
> The FIDO alliance has published a new website promoting FIDO2 for both
> consumers and providers. FIDO2 includes Yubikey and other key vendor
> support, as well as biometrics (facial scans and fingerprint), and personal
> PINs.
> 
> https://loginwithfido.com/provider/
> 
> This is an established and well-supported standard, defined by both the FIDO
> Alliance and W3C's webauthn. Just dropping this here as I think it might be
> a better, all-encompassing approach to authentication in general, beyond
> just adding 2FA, and is way easier for the end-user with its multiple
> supported authenticators, not just a single vendor's hardware key.

Sounds good to me.
Comment 9 Michal Denar 2022-04-22 09:23:55 UTC
Hi,
can we add this feature as extension of Bug 28786? HW USK key is "one touch" as opposed to TOTP, which requires writing code from apliaction from toter device, usualy smartphone?