Open mabramux opened 4 years ago
I have noticed this behaviour on OpenBSD 6.7 (amd64) as well. Firefox just wants me to tap the key while chrome wants the PIN first.
One thing, i am using ssh -K in my xinitrc, maybe firefox communicates with the agent?
I think this might be caused by Firefox using FIDO U2F, while Chrome uses FIDO2 by default. Some time ago a behavior was added to the firmware to accept signing requests from both and produce the same result for compatibility, otherwise registering would lock to the used browser with later logins.
I think this might be caused by Firefox using FIDO U2F, while Chrome uses FIDO2 by default. Some time ago a behavior was added to the firmware to accept signing requests from both and produce the same result for compatibility, otherwise registering would lock to the used browser with later logins.
I'm sorry, but from my point of view the behaviour remains a security issue. From the perspective of an end user I don't expect a compatibility "feature" to access a service with every browser (in my case the service is a instance of nextcloud), but I expect that nobody can use my solokey without a pin.
I suggest to forbit a login in any case if an application does not support the PIN functionality of FIDO2 (only if a pin was set, of course). An "optional" pin is useless from the perspective of security.
If Firefox use FIDO U2F instead of FIDO2, I think this is an further issue of firefox, which we can't resolve here.
If a PIN is set, then it is only required for registration/makeCredential. It is still optional for authentication/getAssertion. This is in the webauthn spec.
In the assertion data that is signed by the authenticator, there is a User Verification (UV) flag. If PIN was verified, then the UV flag will be set. If PIN was not verified, then UV flag will not be set. It is then on the relying party to enforce whether or not the UV flag needs to be in the assertion.
There's a new extension that's not finalized yet called credProtect where credentials can be created with options for authenticator to require UV, but that extension would also need to be supplied by the platform.
@conorpp
If a PIN is set, then it is only required for registration/makeCredential. It is still optional for authentication/getAssertion. This is in the webauthn spec.
Ok, I didn't read the whole spec. I'm only an user, not a developer. ;-)
But I tested again with my Nextcloud instance. Even during registration of my device, I'm not asked for a PIN (using Firefox). And you wrote, that there it is a required feature (and not optional). At least this seems to be an error, according to your explanation.
Perhaps we should alter the title of the issue to "Registration without PIN possible although PIN set (WebAuthn)"
In the assertion data that is signed by the authenticator, there is a User Verification (UV) flag. If PIN was verified, then the UV flag will be set. If PIN was not verified, then UV flag will not be set. It is then on the relying party to enforce whether or not the UV flag needs to be in the assertion.
Okay, that means it would be up to Nextcloud to check the UV flag. But at the moment this would be counterproductive, because then you could only use Webauthn (with PIN) with Chrome as WebAuthnAPI. Am I getting this right?
I suspect the registration is using U2F then instead of FIDO2. Firefox does support FIDO2, so it may be that the client side is using the old U2F API instead of the newer FIDO2/webauthn API. https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
After reading the specification, I think I have understood that the UV can be used optionally on the RP side for both authentication and registration.
I also tried a registration and authentication on webauthn.io and there was the same behaviour like with nextcloud. Only if I set the Option "User Verification" to "Required" I'm getting asked for my pin with Chrome and I wasn't able to register with Firefox.
So my conclusion would be: In fact, everything ist implemented correctly and the client-side decides about the "security-level" (with UV or without).
That means, that on the one hand side the integration of FIDO2/webauthn in Firefox is incomplete. On the other hand this is confusing for the user. Perhaps the spec should be extended to include a passage prescribing better user information. So that every user get a Information while registration, that the UV is part of the client-side.
yeah firefox is a weird one. firefox should imo maybe tell the user that if a required is set that webauthn will straight up not work.
also on any site just using preferred I would rather not rely too much on the PIN, because most sites that only spawn preferred for UV do NOT check whether UV was actually used, so nice that they ask for the PIN but it does in effect nothing if an attacker can literally just swap the preferred for a discouraged in the login (or use Firefox or Android as they both are not capable of either just UV or FIDO2 in general) and get in without any PIN, a behavior I explained and shown to some sites already:
https://blog.my1.dev/webauthns-userverificationpreferred-and-its-pitfalls fun fact I have in my sandbox implementation of WebAuthn exactly something against that. https://my1.dev/wa/my1.php basically once a device has been seen using UV, it sets a flag that can be retrieved and will basically always enforce server side UV validation unless an override is enabled.
Ok, that all sounds, like there is no fault in the implementation by solokey.
But I stand by my opinion. From the user's point of view this is a mistake or at least not transparently comprehensible.
So it is a fault by design (in the webauth standard). And perhaps a fault in some browser implementations.
Perhaps there is someone with a moreunderstanding of technical details, who can explain this to the "webautn consortium". I think, this compromises the security of webauth
yeah FIDO2/webauthn have done many weird things and running preferred as default despite that being something the can lead to dangerous misconceptions for example kinda sux or the fact that you in the FIDO2 protocol cannot register without PIN if set is kinda weird, I mean logging in would be one thing or setting up a resident key but registering is plain weird
If Firefox use FIDO U2F instead of FIDO2, I think this is an further issue of firefox, which we can't resolve here.
Why say that? Perhaps a workaround is to disable the standards you do not like by using about:config
Edit: https://media.fidoalliance.org/wp-content/uploads/2020/05/FIDO-Platform-Browser-Support.jpg It should be fully supported on Firefox anyway. Disabling U2F in favor of Webauthn is your choice.
well not really. u2f vs webauthn seems to affect the JS APIs rather than the hardware level. disabling U2F does not let me enter PIN even on required.
Edit: The only instance where UV MIGHT be supported is Windows 10 1903+ because FIDO2 is done by the OS there, and not the browser
as your pic even shows, CTAP2 on mac (and therefore also all other platforms without OS support directly (linux also) have no CTAP2 in Firefox
Missing the point of my post and who I actually replied to.
If I disable U2F, I surely can disable the OS popups triggered by Firefox on this site: https://u2f.bin.coffee/
Again:
If Firefox use FIDO U2F instead of FIDO2, I think this is an further issue of firefox, which we can't resolve here.
If the wish is to only interact with one out of the two standards, I can reach said granularity on Windows by properly tailoring my tastes in about:config
Edit: And the OP never stated their OS, so bear with me.
okay. well the thing that's confusing is that U2F refers to both the CTAP1 protocol between browser and stick and the U2F javascript API, and then we have webauthn on the browser->website side and CTAP2/FIDO2 on the browser->stick side.
and basically there are the following combinations: U2F JS -> CTAP1 (older websites) Webauthn -> CTAP1 (fallback for U2F sticks or if registering with UV discouraged) Webaithn -> CTAP2 (generally what should be the ideal default)
the firefox option just enables or disables the U2F/webauthn JS APIs, and generally websites run one or the other and not both, so if you kill the one a site uses, it wont work.
If the wish is to only interact with one out of the two standards, I can reach said granularity on Windows by properly tailoring my tastes in about:config
kinda not. this depends entirely on the site you are using. if anything you only make something not work, but you cannot expect to get webauthn from a site using the U2F API by disabling U2F.
If I disable U2F, I surely can disable the OS popups triggered by Firefox on this site:
well you dont just kill the popup, you killed the entire functionality (literally just tested on Windows 10 1909)
Is it somehow possible to force the PIN as a user of the solokey? I mean: I cannot see which options are used by certain services. But I want to be sure that once I lost my solokey, someone who finds it cannot log in with it. When he/she doesn't have to enter a pin, than this is pretty bad from my point of view.
Example: https://webauthn.io
Is it somehow possible to force the PIN as a user of the solokey
as a user less and especially the server would need to check if the pin was actually used
@My1 : Thanks for answering! Since as a user I don't know if the server actually does these checks, I would have to hurry up and deactivate all accounts which use the solokey once I lost it, wouldn't I? How can I typically do this? Since I need the solokey to login...
yes, deactivating is generally the way to go if you lose them, as the PIN only helps while the solo is intact, if one can break open the FIDO device (literally speaking) and extract the keys the PIN protection is literally worthless.
for going into your account you need to have a backup method, either a second FIDO device, or a Recovery code or whatever.
@My1 : Thanks again.
So if I don't have a backup method, the person who finds my key can do whatever the person wants with my accounts and I cannot stop the person. Pretty bad. Maybe TOTP is better suited for me in this case. You need the password and the TOTP generator...
The pin doesn't seem to be used to encrypt the data on the device, so my thoughts about the functionality of the device are probably wrong. Never mind, I probably should have done more research before buying them for all of my team :(
well passwordless FIDO2 has this small issue yes, but password plus U2F/FIDO2 without pin can work on that.
the PIN is just sending a flag along with the credential which the server can check that the device is saying it asked for a pin. how much you can trust this statement is obviously depending on the device. for example feitian recently had some security issues,
Thx, you're certainly right. I'll have to think about these revealings. I will work it out one way or the other. Thx again + best wishes, Uli
but the good thing is FIDO Devices cannot be cloned without destruction (save for some very specific models where backups are part of the design) so passwordless can still be reasonably safe and is still safer than most passwords
well passwordless FIDO2 has this small issue yes, but password plus U2F/FIDO2 without pin can work on that.
Is there a way to enforce without PIN? I want to use the solo keys as 2nd factor only, never for password-less login.
well passwordless FIDO2 has this small issue yes, but password plus U2F/FIDO2 without pin can work on that.
Is there a way to enforce without PIN? I want to use the solo keys as 2nd factor only, never for password-less login.
that's for the website to decide, when they set uv to discouraged (as they should in a second factor scenario) you shouldnt be asked for a pin unless you are registering your solo while have previously set one (FIDO2 is weird from time to time)
I use a Solokey Somu (Firmware version 4.0.0 locked) and set pin with solo-python.
When using Web Authentication with Firefox (Version 76.0.1) I won't be asked for a PIN although PIN set. Instead, login is possible without entering a PIN (only by tapping the key).
Using Chromium (Version 81.0.4044.138) everything is working as expected. I get asked for the pin.
I think the behavior is a big security issue, because using a stick with pin, it should never be possible to login to any account at all. But there seems to be a way to bypass the PIN entry. Otherwise the login with Firefox would not be possible.