mooltipass / minible

Github repository containing the firmwares running on the Mooltipass Mini BLE
GNU General Public License v3.0
98 stars 21 forks source link

WebAuthn Website Incompatibilities Tracker #225

Open limpkin opened 3 years ago

limpkin commented 3 years ago

Some websites incorrectly support FIDO2-only authenticators.

The issue is when we try to register the Mini BLE with these websites the Mini BLE gets a CTAP1/U2F message instead of just a pure CTAP2/FIDO2 message. The Mini BLE reports that ONLY FIDO2 is supported when queried with "GET INFO" message. However, these websites nevertheless send a "CTAPHID_MSG (0x03)" message.

Currently known incompatibilities:

If you'd like to make sure your Mini BLE works, these are the test websites we use:

Up to date list can be found at https://github.com/mooltipass/minible/wiki/FIDO2-Site-Compatibility-Chart

WebmasterTD commented 3 years ago

Would be nice to certify at Cloudflare: https://blog.cloudflare.com/introducing-cryptographic-attestation-of-personhood/ https://cloudflarechallenge.com/

Hypoon commented 3 years ago

DUO Security (duo.com) is used by a variety of organizations to add 2FA capabilities, including one of my universities and my current place of employment. At first glance, Mooltipass appears to meet the DUO's requirements for a security key:

From https://guide.duo.com/security-keys#security-key-requirements:

Security Key Requirements

In order to use a security key with Duo, make sure you have the following:

  • A supported browser (Chrome 70, Firefox 60, Safari 13 or later), or Microsoft Edge 79 or later. Support for authentication is limited to web applications that show Duo's inline browser prompt.
  • An available USB port.
  • A supported USB security key. WebAuthn/FIDO2 security keys from Yubico or Feitian are good options. U2F-only security keys (like the Yubikey NEO-n) can't be used with Firefox.

But further digging reveals a problem.

From https://duo.com/docs/administration-devices#managing-webauthn-devices:

Duo supports a variety of WebAuthn secondary authentication methods when logging in using the browser-based Duo Prompt:

  • Security keys from Yubikey, Feitian, etc. in Chrome v70+, Firefox v60+, Safari v13+, and Microsoft Edge (Chromium-based) 79+
  • Touch ID in Chrome on macOS

When WebAuthn security keys and Touch ID are enabled in your application's effective authentication methods policy, end users can self-enroll security keys via the Duo enrollment prompt or device management portal.

When a user enrolls a security key in Chrome or Edge, it is "dual-enrolled" as both a U2F and a WebAuthn device. The end user can authenticate using that security key in any supported browser, and in Chrome/Edge can authenticate with the security key as soon as the Duo Prompt loads, without explicitly selecting the security key from the drop-down list of enrolled factors. Logging in with Chrome or Edge using a security key that was initially enrolled in a browser other than these two does not initiate this dual-enrollment.

When a user enrolls a security key in a supported browser other than Chrome/Edge, it is enrolled only as a WebAuthn device (no dual-enrollment). It can be used to authenticate in any supported browser, but must be explicitly selected from the drop-down list of enrolled factors.

When I attempt to enroll a security key, I get a window that says "Insert and tap your Security Key to enroll...", but the window seems completely unaware of my Mooltipass Mini BLE (connected over USB at the moment), nor does my Mini BLE seem aware that the window is making a request.

I'm guessing that the lack of U2F support prevents the Mooltipass Mini BLE from being dual-enrolled as DUO wants. I don't have ready access to a non-Linux machine on to test Safari or Firefox (#217), but I found a workaround by using Chrome's developer tools to mimic the user agent of Firefox on Windows. This successfully allowed me to enroll the security key, and the user agent does not need to be configured in order to authenticate.

spoelstraethan commented 3 years ago

I'm having trouble getting the MiniBLE registered with GitHub.com as a Security Key/FIDO2 device as well.

0x0ptr commented 3 years ago

When I attempt to enroll a security key, I get a window that says "Insert and tap your Security Key to enroll...", but the window seems completely unaware of my Mooltipass Mini BLE (connected over USB at the moment), nor does my Mini BLE seem aware that the window is making a request.

I'm guessing that the lack of U2F support prevents the Mooltipass Mini BLE from being dual-enrolled as DUO wants. I don't have ready access to a non-Linux machine on to test Safari or Firefox (#217), but I found a workaround by using Chrome's developer tools to mimic the user agent of Firefox on Windows. This successfully allowed me to enroll the security key, and the user agent does not need to be configured in order to authenticate.

Yes, you are correct. We don't support U2F so MiniBLE will respond with error when it gets the U2F command. However, I find it very strange why you have to go to such great lengths to just use Webauthn. 1) Why don't they actual listen to what the device is reporting as supporting? There is a get info command that they send that will tell them that U2F is not supported and 2) Why not make it an option for the user to select which one to enroll in? Why do they use only Webauthn on non-chromium based browsers? :-)

I guess these are questions for Duo.

0x0ptr commented 3 years ago

I'm having trouble getting the MiniBLE registered with GitHub.com as a Security Key/FIDO2 device as well.

I have had no problems with Github as long as I use a compatible browser/OS combination. What browser and OS did you use? If you tell me what you used I will try to reproduce the issue on my side.

Please note that at least Firefox on Linux does NOT support FIDO2. There is a ticket open on Mozilla to add support to Linux but it has been open for ages but lately there have been some activity on the ticket so hopefully soon... :crossed_fingers:

spoelstraethan commented 3 years ago

I'm using macOS with moolticute 0.50 and the Chrome browser extension (in 2 of the 3 Chrome profiles).

It seems that on the Yubico demo site even without the extension installed I'm able to register the MiniBLE when attached via USB, but Github.com isn't working when I try to register a USB key. It gives me the option of USB security key or this device, which is a TouchID enabled MBP 2015, but selecting USB Security Key doesn't trigger the prompt on the MiniBLE.

0x0ptr commented 3 years ago

I only have a MacBook Air (early 2015) to test on without any TouchID. I am running MacOS 11.4 and Chrome Version 91.0.4472.114 (Official Build) (x86_64). I removed my current security key on my Github account and was able to add it again with this setup. After that I was able to use it to log in.

I also tried with Firefox (doesn't work...same issue as discussed above, Linux/MacOS support is lacking in FF) but Safari worked.

Maybe somehow it is confused because there are two options (TouchID and FIDO2 device). Hmm, are you able to temporary block or disable TouchID to see if it works when you do that? Could you also try Safari?

One little note. You don't need any extensions in the browser for FIDO2 part of MiniBLE to work. You don't need Moolticute/d running either. It is completely independent of that framework. However, you do need to set the time on the miniBLE which requires Moolticute/d but after time is set it is no longer needed as long as battery doesn't run out.

0x0ptr commented 3 years ago

I guess these are questions for Duo.

I have submitted a support request to Duo asking why it is like it is.

spoelstraethan commented 3 years ago

I only have a MacBook Air (early 2015) to test on without any TouchID. I am running MacOS 11.4 and Chrome Version 91.0.4472.114 (Official Build) (x86_64). I removed my current security key on my Github account and was able to add it again with this setup. After that I was able to use it to log in.

I also tried with Firefox (doesn't work...same issue as discussed above, Linux/MacOS support is lacking in FF) but Safari worked.

Maybe somehow it is confused because there are two options (TouchID and FIDO2 device). Hmm, are you able to temporary block or disable TouchID to see if it works when you do that? Could you also try Safari?

One little note. You don't need any extensions in the browser for FIDO2 part of MiniBLE to work. You don't need Moolticute/d running either. It is completely independent of that framework. However, you do need to set the time on the miniBLE which requires Moolticute/d but after time is set it is no longer needed as long as battery doesn't run out.

It wasn't working even after disabling Touch ID, first by unchecking the boxes under the System Preferences > TouchID but that didn't work because Github was still offering to use TouchID or USB, so I had to delete the fingerprints enrolled to completely disable TouchID.

I did get it working thanks to the hint about deleting existing keys, I had previously set up a Yubikey 5 and a Yubikey 4 plus Krypt.co as security keys, and with those present I was totally unable to add the MiniBLE as a Security Key. Once I ended up deleting all the security keys since I also have an authenticator app configured and available to get back into my account if necessary, and I confirmed there were no other security keys, I did get a prompt on the MiniBLE when adding a new key.

The interesting thing when I went to add the Yubikey 5 back was this time it prompted me for a PIN (which I seem to recall Facebook or something requiring for WebAuthN or FIDO2/U2F and I think I'd gotten this key locked out due to not setting it to a value I remember). I'm thinking that when I originally added the Yubikey 5 and maybe the Yubikey 4 to Github they were using either FIDO or U2F and didn't require a PIN, and if that was triggering GitHub to offer those older protocols first for registration, then deleting all the keys and starting with the MiniBLE allowed and then "forced" FIDO2?

Now the odd thing which might be a bug is that when I went to add the Yubikey 5 back, if I had the MiniBLE plugged in it was automatically responding to the auth/registration requests with no prompt on the MiniBLE device, so I had to end up unplugging the MiniBLE to get the Yubikey re-registered, but when having multiple Yubikeys plugged in they only attempted to communicate with the site when touched, so I could have two or more plugged in and only the one I touched to activate would communicate with the site to register as a new key.

0x0ptr commented 3 years ago

spoelstraethan, I was able to reproduce what you are seeing. However, I checked the specification against what we are doing and as far as I can tell we are behaving as we should be. We are returning error code 0x19 indicating that the credential already exists as per specification. So I don't understand why it works when you have two Yubikeys installed on your computer. Maybe because they do U2F? It might be a corner case that Github is not handling properly.

0x0ptr commented 3 years ago

@spoelstraethan I found and fixed some issues that will make MiniBLE behave better when you have another authenticator connected and/or registered. One issue we have is that if you have for example just the Yubikey registered and not the MiniBLE but both MiniBLE and Yubikey connected to the computer then you try to log in and if we follow the FIDO2 specification MiniBLE, miniBLE will immediately return CRED NOT FOUND and Github will give an error. So we have to add an artificial delay before returning that the MiniBLE doesn't have the credential so you have a chance to respond (push the button) on the Yubikey. Currently that delay is anything from 1-3 seconds (that was originally added for privacy reasons). So sometimes the MiniBLE might respond within 1 second and you might be too slow to push the Yubikey button....

But with these fixes you should be able to register both authenticators without having to disconnect the other one... :-) Could you try it out if its not too inconvenient for you? Make sure you delete the FIDO2 cred. from MiniBLE in Moolticute if you remove it from Github...

0x0ptr commented 3 years ago

I'm guessing that the lack of U2F support prevents the Mooltipass Mini BLE from being dual-enrolled as DUO wants. I don't have ready access to a non-Linux machine on to test Safari or Firefox (#217), but I found a workaround by using Chrome's developer tools to mimic the user agent of Firefox on Windows. This successfully allowed me to enroll the security key, and the user agent does not need to be configured in order to authenticate.

@Hypoon I contacted Duo security about this issue and the feedback I got was that Duo customers can disable U2F authenticator devices in policy, but this will force only webauthn enrollment to occur (organization wide policy, might not be desirable though...)

However, still waiting for a response to the fact that they try to enroll BOTH U2F and FIDO2 when the key clearly identifies itself as a FIDO2 only device. I hope they can fix this (if they acknowledge that this is a bug... :-)

spoelstraethan commented 3 years ago

@spoelstraethan I found and fixed some issues that will make MiniBLE behave better when you have another authenticator connected and/or registered. One issue we have is that if you have for example just the Yubikey registered and not the MiniBLE but both MiniBLE and Yubikey connected to the computer then you try to log in and if we follow the FIDO2 specification MiniBLE, miniBLE will immediately return CRED NOT FOUND and Github will give an error. So we have to add an artificial delay before returning that the MiniBLE doesn't have the credential so you have a chance to respond (push the button) on the Yubikey. Currently that delay is anything from 1-3 seconds (that was originally added for privacy reasons). So sometimes the MiniBLE might respond within 1 second and you might be too slow to push the Yubikey button....

But with these fixes you should be able to register both authenticators without having to disconnect the other one... :-) Could you try it out if its not too inconvenient for you? Make sure you delete the FIDO2 cred. from MiniBLE in Moolticute if you remove it from Github...

What do I need to do to get the updated firmware.bin, do those get uploaded to releases or are they hosted elsewhere with GPG signatures or checksums?

0x0ptr commented 3 years ago

What do I need to do to get the updated firmware.bin, do those get uploaded to releases or are they hosted elsewhere with GPG signatures or checksums?

@spoelstraethan The fix should be available in the next release that @limpkin pushes out.

limpkin commented 3 years ago

Updates are now available at www.themooltipass.com/updates :)

ai212983 commented 3 years ago

@limpkin What if I want to gift my device to someone? He should use my email to get the update?

Besides, it would be nice to have most recent version somewhere on that page.

spoelstraethan commented 3 years ago

@spoelstraethan I found and fixed some issues that will make MiniBLE behave better when you have another authenticator connected and/or registered. One issue we have is that if you have for example just the Yubikey registered and not the MiniBLE but both MiniBLE and Yubikey connected to the computer then you try to log in and if we follow the FIDO2 specification MiniBLE, miniBLE will immediately return CRED NOT FOUND and Github will give an error. So we have to add an artificial delay before returning that the MiniBLE doesn't have the credential so you have a chance to respond (push the button) on the Yubikey. Currently that delay is anything from 1-3 seconds (that was originally added for privacy reasons). So sometimes the MiniBLE might respond within 1 second and you might be too slow to push the Yubikey button....

But with these fixes you should be able to register both authenticators without having to disconnect the other one... :-) Could you try it out if its not too inconvenient for you? Make sure you delete the FIDO2 cred. from MiniBLE in Moolticute if you remove it from Github...

This is definitely working better with the new firmware, though I discovered that if the MiniBLE isn't unlocked but plugged in when a site is looking for a security key, it seems to instantly respond with "Wrong key" immediately even if I have another security key plugged in that could be the right one.

limpkin commented 3 years ago

Sorry for the delayed answer....

@ai212983 at the moment yes. @spoelstraethan that's expected behavior... we could however look into inviting the user to unlock his device :)

schichtnudelauflauf commented 2 years ago

Any Microsoft property denies usage of mooltipass because they apparently only allow a specific set of keys and require attestation.

My1 commented 1 year ago

The Mini BLE reports that ONLY FIDO2 is supported when queried with "GET INFO" message. However, these websites nevertheless send a "CTAPHID_MSG (0x03)" message.

what platform (Browser/OS) are you trying this on?

I remember that chrome on devices where it actually has control falls back to U2F to bypass the CTAP2 requirement of forcing UV for registration.

On Windows 10 I can get a Registration with Google onto the Mooltipass which goes through Windows Hello, but google's servers reject it in the end, likely because of the entire issue of being self-signed.

U2F-JS has been axed by all chrome-derivatives by now, not sure what Firefox is doing, but iirc even on WebAuthn they only do CTAP1 on platforms they control last time I checked, has been a good while tho. (W10/11 goes through Win Hello, obviously).