WebAuthn: excludeCredentials causes hang on Android
Categories
(Core :: DOM: Web Authentication, defect, P3)
Tracking
()
People
(Reporter: code, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
Firefox for Android
Steps to reproduce:
- Go to https://garron.net/test/webauthn-user-journeys/trusted-device/upgrade/ on an Android device with fingerprint auth, e.g. Pixel 3
- Follow the steps.
From the page:
This journey simulates a situation where an RP implements a trusted device feature, but has users with legacy registrations whose UV & PA status is not known.
These steps simulate the "worst case" where the RP has no information during step 4 about any potential existing registrations that may work with the current device (and therefore all registrations are listed in excludeCredentials).
Step 2 uses:
"authenticatorSelection": {
"userVerification": "discouraged"
}
Step 4 uses:
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"userVerification": "required"
}
// ...
"excludeCredentials: [/* all registered credentials */]"
Step 6 uses:
"authenticatorSelection": {
"authenticatorAttachment": "platform",
"userVerification": "required"
}
// ...
"excludeCredentials: [/* all registered credentials except the one identified in step 5 */]"
Actual results:
After successful fingerprint auth during step 4, the Promise for navigator.credentials.get never returns.
Expected results:
Step 4 fails with an InvalidStateError, since discoverable credentials are not supported on Android.
| Reporter | ||
Updated•3 years ago
|
| Reporter | ||
Comment 1•3 years ago
|
||
Screencap from Firefox 98 on Pixel 3 with Android 12.
Comment 2•3 years ago
|
||
I tested the issue on a Pixel 6 (Android 12) and can reproduce it on Firefox RC 98.2.0 bun not the latest Nightly (2022-03-17). Can you download the latest Nightly version and see if the issue still occurs there?
Comment 4•3 years 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 5•3 years ago
|
||
If this is fixed on nightly I guess I can close it, but I think I want to investigate this a bit before I do because I find it weird that it got fixed without me noticing it. At the very least I should find a duplicate or find the relevant patch.
Anyway, thanks for the report.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Description
•