Hi, thanks for commenting ! You use it now as an alternative to the Google authenticator ( or better instead) so do I . To my mind, it would be much better than an ID driven phone, especially if you use “fake accounts”. I just wonder that not more support this - but maybe I should not wonder as a lot of companies want your (identified) data 
Unfortunately, we need to wait some more month as this is not in the stable build yet, as far as I can see. But good news indeed.
Sudoing with the Nitrokey FIDO U2F anyone?
Privacy Handbook has an article which recently was updated how to install and configure 2FA on your local box using the PAM package:
Their toot ( https://mastodon.at/@infosechandbook/101970576765486969 ) had the following notes:
– besides YubiKeys, you can also use Nitrokeys, or SoloKeys
– there are many more scenarios for U2F/WebAuthn
– post your own scenarios to help others
We have mentioned PAM at USB Dongle Authentication as well, but without as nice tutorial, as this one. Thank you for linking!
Just a quick corrections to the FIDO U2F devices comparison article (we should send them a toot too):
- Sometimes, U2F secrets are generated by the manufacturer of the security token, then stored on the device and can’t be replaced afterwards. In theory, manufacturers could copy your secret U2F key.
Nitrokey FIDO U2F allows to reset its secrets via a Python client application (‘factory-reset’).
- The Windows 10 update of September 2018 rendered the Nitrokey App useless. Due to this, users can’t access stored passwords and TOTP codes. (Last update: 10/31/2018)
We have offered a free replacement / firmware update due to that issue (edit: limited to devices with old firmware for users unable to use them through Nitrokey App on Windows 10).
Have you tried pam_u2f with NK’s ? I was wondering as it requires some yubico libraries …
I have not tried it by myself, but as far as I got it from description, it should work with any U2F device.
OK, I will give that a try and tell you afterwards 
I think it depends a bit from the HW Configuration that is used through the libraries libu2f-host and libu2f-server from Yubico. I assume they use a USB Vendor-ID etc to recognize their key. But I will test it …
Sure! Please do. It should work - our device is mentioned in libu2f-host: https://github.com/Yubico/libu2f-host/blob/master/u2f.conf.sample#L103.
1 Like
Cool ! Thanks for checking that !
I’ve been using it for more than a week. Works just fine once you configure pam to your liking.
1 Like
Thank you for your reply it helped me a lot too! But then I see that you and other posters mentioned that the key works ‘in browsers’. What does this mean? Does it mean that the browser itself will help with the FIDO U2F, even on sites that don’t have it, or are we still limited to the 10 or so odd sites listed on dongleinfo?
Usage of FIDO U2F device is not limited to the browser, but particularly it was designed for it.
Browser has to have integrated FIDO U2F support, particularly implementation of U2F protocol to communicate with the device, and support Javascript API for handling the FIDO U2F features dynamically on the web page.
Web page side, it has to store public key of the device, so it could verify the signature, thus requires additional effort from the given web service to support it.
Hopefully it will become widely used in the near future, as has became OTP for 2FA. Support for nearly all browsers is added, and all main services are pushed to work with FIDO U2F / FIDO2 standards.
1 Like
@szszszsz thanks for the reply! Makes sense, both the browser must support this new kind of send/receive and the website itself must be able to handle the stuff.
When you look in Germany on teh articles of a big computer magazin, it looks like FIDO get some support. There was a big debate about pro’s and con’s. and one major argument was a HW defect could lead into trouble. So I hope a FIDO2 NK could be (identical) copied to another FIDO2 NK for backup purpose ?
For that one should have 2 devices, both registered to same service, and the second would act as backup. FIDO specifically argues against cloning device secrets.
Edit: discussed in: Backup / Restore U2F secret?
Nitrokey FIDO U2F or FIDO2 devices can’t be cloned. The reasons are:
- FIDO specifications demand non-clonable devices. Instead the approach to deal with defect or lost devices is to configure multiple devices (or other means of two-factor authentication) to your accounts. This allows to recover your accounts in case of loss or defect. This approach has the disadvantage of additional effort which becomes increasingly more effort the larger the amount of accounts.
- If we would violate FIDO’s specification and provide clonable devices we would introduce the following risk: An attacker could buy a few Nitrokeys, initialize them and clone them and provide them to his target claimed as ordinary FIDO devices. His target would potentially use them because he couldn’t distinguish them from uncloned devices (or doesn’t know about cloning at all). It’s a kind of man-in-the-middle attack for which we couldn’t find a good solution yet.
We would prefer a better vendor-independent and officially specified solution to this challenge. We are following such developments but as of now there isn’t another “official” solution yet. Nevertheless we might change our mind in the future, if there doesn’t emerge a better “official” solution soon.
Ok, at least a possibility for a solution. I think to get rid of passwords would be great. Currently my only concern is, that the FIDO2 will not be supported by all devices I have: e.g. iPad and iPhone might be a trouble maker, while iMac, MacBook and all my FreeBSD Server / Pi will work fine
Yeah, ash on my head - I pull back my “clone” request. I thought more on something like the DKEK Shares like used with HSM. So you could make backups and restore on a different FIDO2 in case of a broken token.
The thing is, that every scheme restoring the same secret on another device is an attempt of cloning, which FIDO wants to detect on the server side (by checking the usage counter’s value difference), and this is a feature of the standard. One can of course ignore that, but cannot then call the product compliant with the specification’s design.
Ok, ignoring a spec is not always a good idea - extending it would be ok. So it might be either good to influence and try to change the spec for a generic backup purpose or just make it clear, that back needs to be done by a second type of device. I am good with that.