FIDO2/Webauthn userhandle: does it mean anything

529 views
Skip to first unread message

Philipp Junghannß

unread,
Oct 7, 2021, 5:19:25 AM10/7/21
to FIDO Dev (fido-dev)
Hello, I just have a simple question.

Is there literally any point to the user handle you get with WebAuthn/FIOD2? because isnt the credentialID already enough to identify the credential and then tack that to the user via a backend database, which you need anyway?

It seems just kinda redundant to me.

Regards.

nuno sung

unread,
Oct 7, 2021, 6:15:02 AM10/7/21
to FIDO Dev (fido-dev), My1
Multiple accounts per RP
I thinks this is an example that Microsoft uses the same rpid "login.microsoft.com" for their many services, then different user.id can be mapped to different user under different services. Another benefit is to allow RP to prevent an authenticator to re-register to the same user.id.

My1 在 2021年10月7日 星期四下午5:19:25 [UTC+8] 的信中寫道:

Philipp Junghannß

unread,
Oct 7, 2021, 6:25:54 AM10/7/21
to nuno sung, FIDO Dev (fido-dev)
Multiple users per service aren't an issue considering that you still get the credential id, and for re-registering the same you have exclusion lists

Emil Lundberg

unread,
Oct 7, 2021, 7:21:38 AM10/7/21
to Philipp Junghannß, nuno sung, FIDO Dev (fido-dev)
You're right that it fills largely the same role as the credential ID. The main difference is that the user handle is chosen by the RP, unlike the credential ID which is chosen by the authenticator, so the user handle gives the RP more control over how to structure their database.

And also note that the user handle is (at least intended to be) the same for all of a user's credentials, unlike the credential ID which is unique per credential (maybe obvious, but I've seen that be a point of confusion sometimes).

Emil Lundberg

Software Engineer | Yubico




--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CACHSkNqR13kjmxKjuWEKL%2BM7mGGF4XToNk0MNspmEheMAiZ6JQ%40mail.gmail.com.

nuno sung

unread,
Oct 7, 2021, 7:46:49 AM10/7/21
to FIDO Dev (fido-dev), My1, FIDO Dev (fido-dev), nuno sung
Sure RP can handle these requirements with credential id only just as U2F protocol.
However, the use of user handle can ensure that these requirements are met at in authenticator side.
My1 在 2021年10月7日 星期四下午6:25:54 [UTC+8] 的信中寫道:

Eldan Ben-Haim

unread,
Oct 7, 2021, 8:03:25 AM10/7/21
to Philipp Junghannß, FIDO Dev (fido-dev)
User handles can also be used to "overwrite" registration of resident credentials -- as opposed to exclusion lists.
By sending the same user handle in multiple registration requests, the registered credentials in an RK will overwrite each other.

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.

Aravind Jerubandi

unread,
Apr 7, 2022, 11:43:21 PM4/7/22
to FIDO Dev (fido-dev), Emil Lundberg, nuno sung, FIDO Dev (fido-dev), My1
Isn't Credential ID useful only in case of non-resident keys? And in case of resident keys we can use just the User Handle right? Please correct me if my understanding is not right.

  • And also note that the user handle is (at least intended to be) the same for all of a user's credentials
Let's say I have two FIDO2 keys, and i want to register both with RP abc.com. So on bac.com I'll have the following data under my account. Why RP should use the same userHandle?

 userHandle1 - publicKey1
 userHandle2 - publicKey2

Philipp Junghannß

unread,
Apr 8, 2022, 2:03:56 AM4/8/22
to Aravind Jerubandi, FIDO Dev (fido-dev), Emil Lundberg, nuno sung
the user handle wouldnt be quite enough even with resident key as the user handle is intended to be kept the same for all fido devices of a user, while the credential ID uniquely identifies a specific credential.

and as you need to verify the signature and all against the credential data in the database using the credential ID obviously makes sense. and a credential to user association is something you should have anyway. I mean how crazy would it be be someone could by some way get hand of a userhandle, manipulate a FIDO device into giving that instead and then have the power to log in as that person with just that. sounds crazy.

Emil Lundberg

unread,
Apr 8, 2022, 5:17:11 AM4/8/22
to Philipp Junghannß, Aravind Jerubandi, FIDO Dev (fido-dev), nuno sung
Right, even with resident (discoverable) keys you need the credential ID in order to look up the right public key to verify the signature against, if the user has more than one credential registered. Unless you set unique user handles for each new credential, but that is not how the user handle is intended to be used.

Emil Lundberg

Software Engineer | Yubico



Philipp Junghannß

unread,
Apr 8, 2022, 6:02:54 AM4/8/22
to Emil Lundberg, Aravind Jerubandi, FIDO Dev (fido-dev), nuno sung
so the userhandle basically is just a convenience thing in case someone needs to look up the user directly before checking the credential itself.

is it actually required by the FIDO standard to check it (or even store it in the first place or could one just go off of the Cred-ID?

Regards.

PS: anyone else getting weird "we got your request" replies from ji...@9gphrt.atlassian.net (says something about being powered by Jira Service Management)?

Emil Lundberg

unread,
Apr 8, 2022, 7:59:26 AM4/8/22
to Philipp Junghannß, Aravind Jerubandi, FIDO Dev (fido-dev), nuno sung
One could just go off the credential ID, but it's good practice to check that the user handle (if present) identifies the correct user account (and the same user account as the credential ID). The user handle was added so that RPs won't be required to use uncontrolled data (credential ID) as a primary database index. The user handle is chosen by the RP, so the RP can construct it to fit their database architecture.

Emil Lundberg

Software Engineer | Yubico



Philipp Junghannß

unread,
Apr 8, 2022, 9:08:29 AM4/8/22
to Emil Lundberg, Aravind Jerubandi, FIDO Dev (fido-dev), nuno sung
why would RPs be forced to use the cred ID as a primary Key/primary index just because there's no userhandle?
I mean I have just run an auto-increment id field along the data.
also isnt a primary key supposed to be unique (which it wouldn't be if used as intended)

Emil Lundberg

unread,
Apr 8, 2022, 10:04:37 AM4/8/22
to Philipp Junghannß, Aravind Jerubandi, FIDO Dev (fido-dev), nuno sung
Loosely speaking. Whether it qualifies as a PRIMARY KEY in some given SQL dialect is not the point, it's that you shouldn't have to do the primary lookup based on an ID you don't control (unless you want to, of course). Which would be the case if a credential ID was the only user identifier you had to go by.

Emil Lundberg

Software Engineer | Yubico



Philipp Junghannß

unread,
Apr 8, 2022, 10:09:29 AM4/8/22
to Emil Lundberg, Aravind Jerubandi, FIDO Dev (fido-dev), nuno sung
Oh you meant the lookup, i see. Didn't even think of that (as the the cred-id is base64'd anyway. Especially as in u2f you only had the key handle (which is basically the same) to go by. 

But if the database lookup goes by the user handle would they then neednto try out what fits? Or how would that even go? 

Emil Lundberg

unread,
Apr 8, 2022, 11:56:15 AM4/8/22
to Philipp Junghannß, Aravind Jerubandi, FIDO Dev (fido-dev), nuno sung
An initial lookup by user handle can at least narrow the search space from possibly hundreds of thousands of credentials down to about 1-4 in a typical case, and at that point it doesn't matter much whether you have an index of credential IDs or linear search through them. Likewise in U2F you always had a username or similar for the initial lookup, because U2F did not have discoverable keys.

The difference probably doesn't matter for most applications, but it could in some cases. For example SQL databases typically have fixed-width indices, and credential IDs are of varying length (and for a while, had no defined upper limit on length), which could become significant if you have upwards of millions of records. Especially if, say, a hash collision attack against the SQL engine is found - then malicious actors could flood the database with hash collisions to degenerate the index into a linked list, and execute an amplified denial of service attack by asking the database to look up lots of colliding IDs. This kind of attack has been found against HTTP POST parameters in the past.

Emil Lundberg

Software Engineer | Yubico



Reply all
Reply to author
Forward
0 new messages