Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login without PIN possible although PIN set (WebAuthn) #438

Open
mabramux opened this issue May 16, 2020 · 25 comments
Open

Login without PIN possible although PIN set (WebAuthn) #438

mabramux opened this issue May 16, 2020 · 25 comments

Comments

@mabramux
Copy link

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.

@fbettag
Copy link

fbettag commented May 26, 2020

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?

@szszszsz
Copy link
Contributor

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.

@mabramux
Copy link
Author

mabramux commented May 26, 2020

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.

@conorpp
Copy link
Member

conorpp commented May 26, 2020

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.

@mabramux
Copy link
Author

@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?

@conorpp
Copy link
Member

conorpp commented May 27, 2020

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

@mabramux
Copy link
Author

mabramux commented May 28, 2020

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.

@nickray
Copy link
Member

nickray commented May 28, 2020

@My1
Copy link
Contributor

My1 commented Jun 10, 2020

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.

@mabramux
Copy link
Author

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

@My1
Copy link
Contributor

My1 commented Jun 10, 2020

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

@spacesynth
Copy link

spacesynth commented Jun 19, 2020

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

grafik

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.

@My1
Copy link
Contributor

My1 commented Jun 19, 2020

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

@spacesynth
Copy link

spacesynth commented Jun 19, 2020

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.

@My1
Copy link
Contributor

My1 commented Jun 19, 2020

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)

@uli-heller
Copy link

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

  • chrome: looks good
  • firefox: looks bad

@My1
Copy link
Contributor

My1 commented Jan 22, 2021

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

@uli-heller
Copy link

uli-heller commented Jan 22, 2021

@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...

@My1
Copy link
Contributor

My1 commented Jan 22, 2021

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.

@uli-heller
Copy link

@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 :(

@My1
Copy link
Contributor

My1 commented Jan 22, 2021

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,

@uli-heller
Copy link

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

@My1
Copy link
Contributor

My1 commented Jan 22, 2021

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

@bruelltuete
Copy link

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.

@My1
Copy link
Contributor

My1 commented Dec 14, 2021

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants