Yubikey used for FIDO2/WebAuthn fails to function since MacOS passkey supported added
Categories
(Core :: DOM: Web Authentication, defect)
Tracking
()
People
(Reporter: ben, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:124.0) Gecko/20100101 Firefox/124.0
Steps to reproduce:
Visit a website on a Mac that is configured to request a Yubikey via WebAuthn for MFA. Website prompts for the Yubikey to be touched.
Site was configured to use TouchID with another browser on the device. I removed this setup from the site but it did not change the behavior.
Trying with Firefox 121.0.1 works fine, so the issue starts with 122.0 and continues up to Firefox 124.
Trying with a completely fresh profile (moving ~/Library/Application Support/Firefox out of the way) does not change anything.
Setting security.webauthn.enable_macos_passkeys to false and restarting the browser resolves the problem.
I have a separate Mac where TouchID was never setup for this site and all versions of Firefox still work with the same user/security key regardless of the state of security.webauthn.enable_macos_passkeys. Note there are some differences to the Mac that is failing. Failing Mac is on Ventura 13.6.5, successful Mac is on Sonoma 14.1.2 (I can't easily make these match). The failing Mac also has a configuration profile that enforces DNSOverHTTPS to be disabled, ImportEnterpriseRoots to be enabled and AppAutoUpdate to be on, the successful machine does not have this. In necessary I can disable the configuration profile on the failing Mac but I don't think it's relevant to the issue.
I also have a separate user on the same site that never had TouchID setup for use with WebAuthn on either device and it works fine with both devices and all versions of Firefox regardless of the state of security.webauthn.enable_macos_passkeys.
Note both Chrome and Safari work fine with both user accounts and the Yubikey on both machines.
I cannot share the site in question or make accounts for Mozilla developers to help disagnose. But I happy to help carry out steps to help diagnose the root cause of the problem. Answers may need to have some information redacted though.
Actual results:
After entering the username/password on the site, site displays page asking for the security key to be touched. Site displays spinner waiting for the security key to be touched. Browser does not display the drop down from the URL bar asking for the key to be touched. Key blinks like it can be touched. But touching it does nothing and the site's spinner just keeps spinning. No further progress happens.
Expected results:
Browser should display the prompt to touch the key and properly carry out the WebAuthn process.
I think the Component for this should be: DOM: Web Authentication
|
||
Comment 2•1 year ago
|
||
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.
|
||
Comment 3•1 year ago
|
||
It looks like this may be the same as the one I reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=1886537
Possibly, though your bug is about registration and mine is about usage. However, from the browser's perspective I don't think registration or normal use is any different. At any rate I also noticed I could not register a new Yubikey for the user on the problematic site using the problematic machine. I have not tested if registration is resolved by security.webauthn.enable_macos_passkeys being set to false. But will try that later today and put an update here.
|
|
||
Comment 5•1 year ago
|
||
That's a good point, my repro steps include registration because it reduces the number of external variables, but I should be explicit that the symptoms are the same whether I am registering a new credential or trying to authenticate with a credential that was registered previously.
I tested registration and it does work in 121.0.1 with the account that's broken, does not work in 122.0.1 with the broken account if security.webauthn.enable_macos_passkeys is true, and does work with 122.0.1 with the broken account if security.webauthn.enable_macos_passkeys is false. So yes registration is impacted for me as well and is fixed by changing that setting.
I'm still not sure it's exactly the same problem as your issue you say webauthn is just broken in general. Where in my case it only breaks for a single user on a site. As I mentioned above a different user it works fine (though I didn't specifically test registration since I don't rally want to remove my Yubikey on that user).
I saw that John Schanck [:jschanck] replied on your issue and said this is a known bug on Apple's side with macOS 13 installs that have Safari 17.4 also installed. That is indeed my case. Though his response and your bug makes it sound like Webauthn is totally broken and like I said above that just doesn't seem to be the case for me.
Again I'm more than happy to do further testing or digging to try to get to the bottom of the issue.
|
|
||
Comment 7•1 year ago
|
||
The severity field is not set for this bug.
:jschanck, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Comment 8•1 year ago
|
||
I think it's likely that this is the same issue with Safari 17.4.0. Please let me know if the problem persists after upgrading to 17.4.1.
|
|
||
Comment 9•1 year ago
|
||
The severity field is not set for this bug.
:jschanck, could you have a look please?
For more information, please visit BugBot documentation.
|
|
||
Comment 10•1 year ago
|
||
Comment 6 indicates the reporter had Safari 17.4.0. Closing this as a duplicate of Bug 1886247.
Description
•