FIDO2: Slowness and Errors when going through exclude credential lists

[My1]

Expected behavior

it relatively quickly passing through exclude lists (existing credentials to make sure you dont accidentially register the same device twice)

Actual behavior

on smaller exclude lists (e.g. 4) taking several seconds to get to the FIDO Storage prompt. On Bigger exclude lists (18 in case of my Primary Google Account) it straight up failing after a bit (around 15 seconds here)

According to the log it takes around 3 seconds between the request if a given credential exists and a "sorry I dont have that", which is quite a long time.

Step by step guide to reproduce the problem

1) find a place with WebAuthn 2) register a bunch of other authenticators 3) register the MP

Firmware Version

AUX MCU version: 0.73 Main MCU version: 0.84 Bundle version: 12

Moolticute Version - If Involved

not involved

Operating System

Mention if you are using either: Kubuntu 22.04 LTS

[limpkin]

I can dig into it, but that may be due to the random delay we add to prevent login bruteforcing for standard credentials.

[My1]

I think at least fido creds are not easy to bruteforce anyway as according to the webauthn standard there have to be at least 100 bit entropy inside. maybe it might be usefil to check how other FIDO devices handle it and possibly throw out that delay for fido fails specifically.

[My1]

is there some way the delay could be ignored for FIDO only? because it really breaks the way FIDO operates. https://www.w3.org/TR/webauthn-2/#sctn-createCredential step 3 https://www.w3.org/TR/webauthn-2/#sctn-op-get-assertion equally step 3 basically the entire point is to bonk all known FIDO creds towards the device in order to find a matching one to either prevent registration of a duplicate, or allow signing in with the correct credential for the given account.

[limpkin]

done :)

[My1]

oh cool, cant wait

[My1]

before releasing try having a fido account associated with a lot of credentials previously interact with the MP to make sure all works as planned as I am not sure that the complete fail after 5 is just a function timeout, or the MP blocking after too many reqs in a row

[limpkin]

bundle v13 is available at https://beta-updates.themooltipass.com/ !

[My1]

it certainly is faster but I still get an error 16 (or 0x10) which doesnt seem listed in the specs. I get 10 times error 46 (0x2E, no valid credential sent, so far so normal) but the 11th gets thrown out with an error code 16.

I sent an uncensored pic over via matrix in private

[limpkin]

@0x0ptr would you be able to help? :)

[My1]

I have dug a little and found this: https://github.com/mooltipass/minible/blob/master/source_code/aux_mcu/src/fido2/ctap_errors.h#L16 apparently this error has been in a very old draft version https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authenticator-protocol-v2.0-rd-20170927.html#error-responses and is most likely triggered by https://github.com/mooltipass/minible/blob/master/source_code/aux_mcu/src/fido2/ctap_parse.h#L11-L12 (so far the only instance I found)

now for the fun part. check_ret is littered through the code, and while the code has printf1 and printf2 functions, I have no way how to actually get those if this is even possible on a prod device.

[My1]

Update I think I have the issue.

I didnt dig through tinycbor as that's likely a bit too much but one thing I noticed in the chrome device log is that before failing it went through a credential ID that was longer than the others.

so I went through my credential list on Google and counted out the credentials in order to find 2 who may be the culprit, and went into my Sandbox and narrow stuff down, and yeah I got something.

the eWBM G310 (the company is called TrustKey by now) makes these super long credential IDs

MTJa+UnfRXD0vQqZqgSQAaU4TAN9tp\/tzFJ\/2fkP0cqKQOvHr4fm0E9hgPB1kZqs0lxiOav6VjIJNIqOHDHqLvzijYvh7tlM6VN6telxvjeahUvp3EvflsreHZNL9mpVXzMHE3n5Y502\/Zq3R3dGCeKwW0tfaWP4HE0GVTgHMYo= or 31325af949df4570f4bd0a99aa049001a5384c037db69fedcc527fd9f90fd1ca8a40ebc7af87e6d04f6180f075919aacd25c6239abfa563209348a8e1c31ea2efce28d8be1eed94ce9537ab5e971be379a854be9dc4bdf96cade1d934bf66a555f33071379f9639d36fd9ab747774609e2b05b4b5f6963f81c4d06553807318a in hex which is 256 hex chars or 128 Bytes worth of credentialID

you can test here: https://my1.dev/wa/my1.php

with your MP connected you can do the following:

1) Enter Test-MP into the User ID Field 2) Click Register to obtain registration request from server 3) the data of that request will be visible on the site 4) click the white (Re-)start Webauthn Signup button to actually let the browser get webauthn request 5) see the error in the device log

[limpkin]

uh that's going to be a fun one...

[My1]

Is there a way too see the printf1 and 2 outputs tho? Like where does it print to?

[My1]

Stupid idea, i assume mooltipass's cred ids are severely smaller than that, could it just see that this thing is too big and throw it out if there's a bigger issue you can't easily deal with?

[limpkin]

on the mini ble dev board we do have a debug uart, however in that case I think there's a define somewhere that allows sending the debug messages over USB. your assumption is indeed correct... we support 16 bytes ATM: https://github.com/mooltipass/minible/blob/master/source_code/main_mcu/src/NODEMGMT/nodemgmt.h#L233 we could repurpose that one though: https://github.com/mooltipass/minible/blob/master/source_code/main_mcu/src/NODEMGMT/nodemgmt.h#L245 but what does the standard says about credentials IDs? we didn't put 16 bytes just for fun...

[My1]

I think there's a difference between what you ppl use and what you ppl can deal with while not totally breaking. I need to check the variety of different fido devices i have access to and their cred id length.

Like if you really only need a secure identifier or whatever 16 bytes or 128 bit is enough but i think that's certainly on the lower end of the scale and most should have more

Basically you don't need to step away from using 16 yourself but just not break with longer ones but just say "yeah i don't know that".

If you check the image i sent you in matrix you can see different credential id lengths the mp did handle, and i am pretty sure most should be longer than 128 bit, but not as absurdly long as the G310

[My1]

I don't have a debug Board so I'd likely need that usb thing. Not sure if and how i can look at stuff using retail fw. I didn't check for a hidden serial device or whatever yet

[limpkin]

ohhhh I'm with you now... sorry, that took me a while. in that case that should be an easy fix... pinging @0x0ptr where did you send it on matrix? I didn't see anything

[My1]

I sent it to you in a private chat

[limpkin]

Uh I didn't receive it...

[My1]

okay that's weird, I mailed support@mp with the image.