Closed Bug 1836722 Opened 1 years ago Closed 1 year ago

WebAuthn prompt cancels immediately when trying to authenticate with WearAuthn device

Categories

(Core :: DOM: Web Authentication, defect, P2)

Firefox 114
defect

Tracking

()

RESOLVED FIXED
119 Branch

People

(Reporter: mrconorae, Assigned: jschanck)

References

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0

Steps to reproduce:

  • Go to webauthn.io
  • Enter a sample username
  • Click "Register"

Actual results:

  • The "connect a security key now" prompt appears, then dissapears again almost immediately
  • The site shows an error - "The authenticator was unable to process the specified options, or could not create a new credential"
  • No errors are shown in the site or browser console

Expected results:

  • I should be prompted to authenticate, but instead the authentication prompt never appears to actually trigger, as my security key doesn't prompt me for input.

A few additional notes:

  • I've tried these steps in Chrome as well (same device, same key) and it works correctly - so I doubt this is an issue with my hardware or operating system.
  • It did previously work on Firefox, up until about 112 if I recall correctly, but I've only noticed now.
  • I've already tried the following troubleshooting steps, none of which helped:
    • disabling Tracking Protection
    • restarting to Troubleshoot/Safe Mode
    • refreshing Firefox
    • reinstalling Firefox

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Web Authentication' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: Web Authentication
Product: Firefox → Core

Can you share what kind of security key you have (manufacturer and model)?
And also, does this happen for every page, or only specific ones?
You could also try demo.yubico.com and/or webauthn.io to test if it happens all the time.

The security key I'm using is a WearAuthn key (an Android watch), which appears as a standard USB security key to the host. I'm not sure what manufacturer/model it'll appear as, because it carries the traits of the Bluetooth device it's emulating. For me at least, it's "OPPO Watch", but it doesn't appear in lsusb. Note that it's allowed explicitly on the host machine (Ubuntu) through u2f-hidraw-policy, and it's worked fine across desktop Firefox and my Android phone for a while (> year) previously.
This happens for every page that uses WebAuthn - including test sites (e.g. yubico.com and webauthn.io), and for actual login (e.g. Cloudflare, GitHub).

Thanks for the quick reply. Let me know if you need any more information!

More info about WearAuthn: https://github.com/fmeum/WearAuthn

Thanks for the info!

Could you double-check if under about:config, the setting security.webauthn.ctap2 is true?
If so, does it work with the setting set to false?

Then, please set it back to true, and run Firefox from the commandline with RUST_LOG=authenticator=debug firefox.
Maybe we can see some logs giving us an indication to what goes wrong.

OK, security.webauthn.ctap2 was initially true (the default value).
Setting it to false fixes the issue, and authentication works correctly.

With ctap2 back to true, and with the logging enabled, attempting to authenticate gives the following output:

[INFO  authenticator::statemachine] error happened with device: Error: requested operation is not available on device
[INFO  authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw4")): Permission denied (os error 13)
[INFO  authenticator::statemachine] error happened with device: Error: requested operation is not available on device
[INFO  authenticator::statemachine] error happened with device: Error: Ioerror(Some("/dev/hidraw3")): Permission denied (os error 13)
[INFO  authenticator::statemachine] error happened with device: Error: requested operation is not available on device
[INFO  authenticator::transport::platform::device] new device "/dev/hidraw5"
[INFO  authenticator::statemachine] Device "/dev/hidraw5" continues with the register process
[ERROR authenticator::statemachine] Error when determining pinAuth: HIDError(Command(UnsupportedPinProtocol))
[INFO  authenticator::statemachine] Statemachine was cancelled. Cancelling transaction now.
[INFO  authenticator::transport::platform::transaction] Transaction was cancelled.

Seems to suggest a permissions error, which is weird considering it works in Chrome, and in Firefox when ctap2 is set to false.

Thanks, that's very helpful. I've opened auth-rs #274 to fix this upstream.

Assignee: nobody → jschanck
Severity: -- → S3
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P2
Summary: WebAuthn prompt cancels immediately when trying to authenticate → WebAuthn prompt cancels immediately when trying to authenticate with WearAuthn device
Depends on: 1837473

We landed a fix for this in Nightly. Could you confirm that it's working?

Flags: needinfo?(conoreager)

What Firefox version would that be? I'm using the MozillaTeam firefox-next PPA on Ubuntu (because Snap causes problems with some extensions I use), and I'm not sure if that counts as the 'nightly' stream.

Looks like MozillaTeam firefox-next tracks the beta stream, which is currently Firefox 115. Nightly is Firefox 116.

We had to back out the patch for an unrelated issue. So it's not currently fixed in 116 either.

Depends on: 1839517
No longer depends on: 1837473
Target Milestone: --- → 118 Branch

Have you had a chance to test this recently, Conor? It should be fixed in the Ubuntu package that you use now.

Status: ASSIGNED → NEW

Yep, it appears to be working!
I set security.webauthn.ctap2 back to the default value (true), and tested it using my key on WebAuthn.io. I could successfully register and authenticate, no problems. Thanks for your work on this!

Flags: needinfo?(conoreager)

Great, thanks for checking!

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: 118 Branch → 119 Branch
You need to log in before you can comment on or make changes to this bug.