Firefoxseems to have a problem on Linux using USB Security Keys. I have two Yubico Security Keys which I use for 2FA. The problem seems to be that Firefox cannot communicate with the USB port, as it doesn't make any difference whether the USB Security Key is plugged in or not, the error returned is always the same and the Security Key does not light up.
I've used a number of sites (I've listed a couple below) where you can test your Security Key with Firefox on KDE Neon and the error is always "UnknownError: The operation failed for an unknown transient reason":
As you suggested, downloading the official version of Firefox from your website solved the problem. I will post a ticket on KDE Neon's bug tracker that their default installation of Firefox is not configured properly.
This isn't actually a firefox problem. KDE Neon uses the firefox package from the Mozilla Team PPA and there's nothing wrong with that package. The problem is that Neon enables app armor on firefox which breaks access to password managers and security keys. sudo aa-disable usr.bin.firefox works around the problem by disabling app armor for firefox. aa-complain was not sufficient in this case.
Given that the
live.com site only supports passwordless login via CTAP2, and this metabug is marked as a P1 for the last 7 months, could we get an update? It's unclear what the status is for authenticator-rs to support CTAP2, and that's the only dependency I'm seeing (which is curiously marked as a P3 for this P1 metabug).
I'm busy elsewhere at present; I keep hoping I'll have some free time to work on WebAuthn soonish, but there's nothing definitive planned. Realistically, I have to rework the UX before I can really integrate the CTAP2 branch of authenticator-rs properly (since I need to do things like solicit PINs) and what passes for a WebAuthn UX today is currently broken anyway (Bug 1573190, Bug 1540309, Bug 1579927). So I need to learn how to do UX design as a practical prereq, which makes it harder to just casually work on.
Any update on this? We are using FIDO MDS to verify attestations and only get useless fido-u2f type attestation statement (no aaguids included) with Firefox on Linux. This works fine in Chrome. I believe it's related to this issue. The situation forces us to put disclaimer on our service: "Do not use Firefox for FIDO2 token registrations". It makes me sad since Firefox has always been my favourite browser. Hope this will move forward.
How can Firefox claim to be all about Privacy, Security and Speed when it doesn't support the greatest improvement we have ever had to all of those things when it comes to logins? I expected Firefox to be the very first to get this working, not the last.
Currently someone from SUSE has been working on authenticator-rs. They really want to see webauthn added to firefox and have been working for weeks on CTAP2 support now. You can check out -rs/pull/150 -rs/pull/154 and their own development branch on -rs/tree/ctap2-cont
Thanks for the update and suggestion. Can we prioritize this item? It has a large impact on 2 major tech companies.
Also, do you have an estimated completion date when FIDO2 will be available on Mac and Linux?
Currently Microsoft doesn't support FIDO2 keys while using firefox on linux or MacOS.
(see -us/azure/active-directory/authentication/fido2-compatibility)
Just for my understanding: Would resolving this bug result in MS being able to support FIDO on linux/MacOS?
Just for my understanding: Would resolving this bug result in MS being able to support FIDO on linux/MacOS?
It would, at least if MS allows the User Agent of Firefox for Mac/Linux to see this feature (otherwise you would have to switch your user agent) like they didn't do with Safari.
Folks, while it's great to see there is a lot of interest in this, please don't post "+1" comments. We know that this is important (it is a P1, after all) and people are actively working on it. It will be done as soon as it's done, and posting more comments isn't accelerating that process.
Any updates on the estimated completion date on this P1 item? This bug has been open for 4 years (since 2/25/2019) and impacting customers from raising the security bar to migrate to FIDO2 security keys; ultimately driving millions of users AWAY from using Firefox. Google Chrome, Microsoft Edge, and Safari support FIDO2 for years now. Also, U2F is a deprecated API and major security token providers only sell FIDO2 tokens. Currently, Firefox only supports U2F on Mac and Linux, and with that, this is a critical security blocker.
On a different note, can someone from Mozilla provide a knowledge transfer so that we understand the blocker and the remaining work? Is there a feature branch we can test FIDO2 in Firefox on Mac and Linux? I'm curious to know the current state of the FIDO2 support in Firefox. Thanks.
I've written a FIDO2 (WebAuthn) and FIDO U2F platform library in Rust [1], for Linux. It's a WiP, but it already supports the main FIDO2 ceremonies, both FIDO2 PIN protocols, and downgrading WebAuthn for U2F devices (as per specs). I've tested this with as many security keys I could get my hands on so far [2]. It's designed to have pluggable transports, currently supporting HID and BLE (via Bluez), and plans for NFC and caBLE.
As mentioned before, whilst it could be used directly as a library, the main objective is to provide a backend for new D-Bus platform APIs. Secondary goals include supporting TPM platform authenticators, and supporting containerised applications (e.g. Flatpaks[3]), without requiring access to the USB stack, or BLE adapters.
I'm trying to gauge interest in Firefox delegating U2F and FIDO2 to the platform. If this sounds feasible, as the next step I will try and reach out to GNOME shell folks. I reached out earlier to some System76 engineers working on the Cosmic DE, as they may also be interested.
is there any way to fail with a friendly message when a FIDO key is plugged in, but the site requires FIDO2? this has gotten me on other sites as well. Most browsers do not handle this well, though this may be faulty logic in the HTML/JS app or in API calls.
A few sites let me enroll the FIDO device. However, each site that fails does so in a very cryptic way, which usually leads me into setting a breakpoint or examining DOM and JS. It's happened on Google, Github and my school's authentication (which formerly only supported FIDO and not FIDO2).
The reason these clear error messages important: for everyday people, tangible objects are an excellently simple way to be secure. FIDO and webauthn are about as simple as needing your keys to start your car. Very easy to explain and it's very easy to do, if the enrollment and authorization process is simple.
Most people have MFA-method fatigue and may be unwilling to adopt a novel method, even though it's simpler. However, the second that an everyday person encounters the unending onslaught of crypto acronyms, they'll reject this newer method. I also did not quite realize that passkeys would default to my yubikey.
The one other aspect that's confusing for hardware passkeys is enrolling multiple yubikeys. I don't think the average person would take the time to enroll both keys. The platform/browser keys used for passkeys aren't really satisfying. I guess a third-party service like OpenID or the newer auth startups would work.
apologies if this is a duplicate. my account is new, so maybe manual approval is needed. also, this might not be the correct place for my question, but it seems related, since I encountered it when enrolling for Github passkeys.
The one other aspect that's confusing for hardware passkeys is enrolling multiple yubikeys. I don't think the average person would take the time to enroll both keys. The platform/browser keys used for passkeys aren't really satisfying. I guess a third-party service like OpenID or the newer auth startups would work
When accessing My Nintendo, which doesn't support Passkey in the current version, I found sign in with Passkey became possible, and there was no longer a warning about "partial passkey support" on GitHub.
I have been using Firefox for a long time and I am grateful that the project is alive thanks to many people. I would like to know the current status of support for passkeys and webauthn for Firefox (desktop for Windows) and Firefox for Android.
macOS prompts me again to store the key in iCloud Keychain instead of FFs password manager. Basically this makes the whole passkey implementation useless, since the whole point of FF having passkey support is to store the key in FFs password manager so I can sync the key between all OSes FF runs on.
3a8082e126