Bug 220415

Summary:	[WebAuthn] Safari ignores maxMsgSize in Message encoding
Product:	WebKit	Reporter:	login Llama <loginllama>
Component:	WebCore Misc.	Assignee:	Nobody <webkit-unassigned>
Status:	NEW ---
Severity:	Normal	CC:	garrett_davidson, jiewen_tan, matthew, nuno.sung, paulschreiber, webkit-bug-importer, will.smart
Priority:	P2	Keywords:	InRadar
Version:	Safari Technology Preview
Hardware:	iPhone / iPad
OS:	iOS 14
Bug Depends on:
Bug Blocks:	181943

Description login Llama 2021-01-07 08:29:49 PST

The problem can be reproduced on https://webauthntest.azurewebsites.net/ or other test pages by registering 12 or more credential ID with authenticator A, then register Authenticator B (Registration can be done on any platform.) Tests were done with a Yubikey 5 NFC, other keys will behave the same but may have different sized credentialID and or transport buffers.

On iOS use Authenticator B to authenticate via NFC tap.

The encoded request will be larger than the 1200byte maxMsgSize supported by a YubiKey

The authenticator will appear unresponsive.

Over NFC the authenticator will return a NFC layer error SW_DATA_INVALID. iOS is not capturing that error and continues to wait for a response.

Over USB the behavior is harder to debug.
Due to transport differences a CTAP error is returned TAP1_ERR_INVALID_LENGTH after the first APDU is received.

iOS seems to continue sending APDU but eventually stops and retries using CTAP1/U2F commands if user verification is set to discouraged at the WebAuthn level.

If we look at Message encoding https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#message-encoding
The platform needs to look at maxMsgSize and not send larger messages.

The current code clearly breaks over NFC with a large allow list and over USB with a large allow list if user verification is required.

In get Assertion 6.2.1 https://fidoalliance.org/specs/fido-v2.1-rd-20201208/fido-client-to-authenticator-protocol-v2.1-rd-20201208.html#sctn-getAssert-platf-actions step 1.1 pre-flight is discussed as a way to process large allow lists.

The getInfo maxCredentialCountInList (0x07) and maxCredentialIdLength (0x08) should be used to filter the allow list and batch credentalID into requests with PinTokens to step through the allow list rather than falling back to U2F.

This has been seen to be a problem over NFC with Google Advanced Protection accounts when multiple authenticators are registered. As Google sends uv discouraged authentication the U2F fallback works for those accounts over USB.

There are other sites that set user verification preferred or required in WebAtuthn, those sites will break over both NFC and USB if the allowlist is too large.

In the short term over NFC you could try immediately falling back to U2F if the allow list size would cause a request to be too large.

The correct long term solution is to refactor the code to properly deal with large allow and exclude lists, using the information in getInfo.

I hope the additional platform info in CTAP2.1 can help explain things.

Comment 1 Radar WebKit Bug Importer 2021-01-14 08:30:24 PST

<rdar://problem/73199796>

Comment 2 login Llama 2023-07-20 10:16:55 PDT

This is an ongoing issue.  

With sites like Github allowing multiple credentials to be registered, The allow lists are starting to trip this issue.  The user sees the no credentials error for the authenticator once the list gets too big, until they delete one on the server, and then it works again.

8 to 10 credentials triggers this depending on authenticator.

Comment 3 login Llama 2024-07-18 12:55:27 PDT

Safari still overflows the buffer when the allow list is too large.

The problem impacts Microsoft logins the worst, as they tend to have longer allow lists for various reasons.  

The main cause of the problem is that unlike all the other browsers Safari is not batching requests.

Microsoft has two flows, one that uses discoverable credentials, and one where the user enters their userID then selects "Other ways to sign in" rather than entering the password.  It is this flow that uses an allow list and breaks.

Comment 4 nuno.sung 2024-07-19 00:09:03 PDT

I also encounter this issue on MSA or test with 9+ credential-id through https://webauthntest.identitystandards.io/ on ios 17.5.1 and 18.0 Beta 3.

Comment 5 Paul Schreiber 2024-07-22 07:08:40 PDT

This is reproducible on google.com as well. Apple folks, see FB12203884 (filed May 2023).

Comment 6 nuno.sung 2024-07-22 22:35:31 PDT

Not only with excludeList/allowList cases, some rp add all supported algo when doing make() also will trigger this issue, e.g.
---
{ "attestation": "direct", "authenticatorSelection": { "residentKey": "discouraged", "userVerification": "preferred" }, "challenge": "a0oPIQ4k5mF15rK1WKnUxqGsRYvsC-0tHf3er8i0LZHTv8f4KGUMRQ1ys- aJiFg0_OuIPhKA8ecaRuUmfHN3EQ", "excludeCredentials": [ {"id": "iNRyobHFV_khWBgdUXpkeNxVFjRh2MIZI7YSJt4qBDTsK1kwQ8H6DmqixmZM2jRIbhXpbSV_UN_9GK4PcuMYv4EMReqzRhIPAgggCK21ouy4fHE HUFHHAYdMTC6d8Q", "transports": [ "usb", "nfc", "ble", "hybrid", "internal" ], "type": "public-key" }, { "id": "vxwsDOgJ08syZrS13YAEXS7UV51B0rb8гBTm92NJvWaxMEQOUkc2L_Nvs Se6Cprd@VG5Wt-0WUcuDx5xdomaIA", "transports": [ "usb", "nfc", "ble", "hybrid", "internal" ], "type": "public-key" } ], "extensions": { "credProps": true }, "pubKeyCredParams": [ { "alg":-65535, "type": "public-key" }, { "alg":-257, "type": "public-key" }, { "alg": -258, "type": "public-key" }, { "alg": -259, "type": "public-key" }, { "alg": -37, "type": "public-key" }, { "alg": -38, "type": "public-key" }, { "alg":-39, "type": "public-key" }, { "alg": 7, "type": "public-key" }, { "alg":-35, "type": "public-key" }, { "alg": -36, "type": "public-key" }, { "alg": -8, "type": "public-key" }, { "alg": -43, "type": "public-key" } ], "rp": { "id": "binance.com", "name": "Binance" }, "user": { "displayName": "Chrome V126.0.0.0 (Windows)", "id": "NDg2MTA4NDIz", "name": "xxxxxx.user1@gmail.com" } } 
---