Preventing privacy leak via credential IDs

Skip to first unread message

Otto Krüse

Oct 24, 2022, 9:35:46 AM10/24/22
to FIDO Dev (fido-dev)

The WebAuthn spec uses *could* language to describe how a Relying Party could prevent attackers from acquiring valid credential IDs for actual users:

Considering there's effort (or UX trade-offs) involved in implementing such counter measures I suspect that many Relying Parties (implemented by developers, i.e. humans) are not gonna bother with it. Meaning, they'd just return credential IDs given only a username.

Is there any de facto way of properly doing this (or not), that might not (yet) be in the spec?

I'd appreciate to hear any views people have, and what they have seen in the field.

Thank you,

- Yes, I'm a developer considering whether or not to implement such counter measures ;)

Tim Cappalli

Oct 24, 2022, 9:40:18 AM10/24/22
to Otto Krüse, FIDO Dev (fido-dev)
The second bullet point is probably the best advice as we start moving to a passkey-centric world (passkeys are discoverable credentials that can be used with the new autofill UI).

If this is a new FIDO2/WebAuthn deployment, I highly recommend you start with passkeys instead of second factor credentials (server-side / U2F).

Check out for more info.

From: <> on behalf of Otto Krüse <>
Sent: Monday, October 24, 2022 06:35
To: FIDO Dev (fido-dev) <>
Subject: [FIDO-DEV] Preventing privacy leak via credential IDs
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
To view this discussion on the web visit

Philipp Junghannß

Oct 24, 2022, 10:07:16 AM10/24/22
to Tim Cappalli, Otto Krüse, FIDO Dev (fido-dev)
maybe but forcing RKs is kinda bad when the most well known FIDO2 key still only supports 25 keys, which is not NEARLY enough for anything really.
and asking for a password when you try passwordless authentication without RKs is kinda beyond the point, also the question what would be worse having a try on a (likely insecure) password or leaking credential IDs. I mean I think WebAuthn before asking for a password as a kinda inverse 2FA seems a lot nicer imo, especially as you often enough have the usernames as the method to correlate users.


Robert Booth

Nov 6, 2022, 8:22:53 PM11/6/22
to FIDO Dev (fido-dev), My1,, FIDO Dev (fido-dev), Tim Cappalli

I think Tim was referring to discoverable credentials in passkeys which are not the same as resident credentials. * correct me if I'm wrong Tim

"as we start moving to a passkey-centric world"??? Really, I think that's a little bit of a stretch. I know GAMA would like that but I don't think that's a near term goal or a solution for everyone.
I really don't want my bank supporting passkeys just like I didn't want them supporting Google sign-on.


You haven't described your environment for a solid answer so I'll wing it a bit.

My first question would be is your user base enterprise or consumer?

The exploit described on that document I feel would come from a nation state attacker or is targeting a very high value target. Getting close to someone to get a security key to retrieve credential ids is a huge risk for someone and they payoff needs to be worth it. 

The customers I've worked with have mostly deployed username/password/security key. They did this because users were mostly okay adding the security key but when you totally switch them away from a password they seem to have more questions. They realize this is a journey to passwordless and just because the tools are available doesn't require you to implement them.

Also, they were able to relax the password policy since they were adding strong authentication with a security key.
If they had specific users they were concerned about for this type of attack they would deploy out security keys that could only be registered with their service, yes those keys exists and I'm not sure you would get that control with passkeys.

The way I deployed on my own app is the following.

username/password -> submit

Server checks if username/password are valid
if yes, send fido auth with associated user creds
if no, send fido auth with random credid that is invalid

Final result would either by successful login for valid username/password/security key
Invalid login. Nothing mentioned about security key or password or even username

Hope this helps and enjoy your journey,


Otto Kruse

Nov 8, 2022, 8:32:09 AM11/8/22
to FIDO Dev (fido-dev),, My1, Otto Kruse, FIDO Dev (fido-dev), Tim Cappalli
Thank you all for your insights.

Indeed I'd like to support passwordless sign-in with non-resident (user verifying) keys.

I'm now thinking of the following approach to balance UX vs security:

1. let users sign-in using "old school" means, e.g. username+pw or magic link
2. after sign-in they can register (user verifying) authenticators
3. their registered credential IDs are saved in browser local storage
4. next time they want to sign-in they can do so passwordless, we can start WebAuthn because we have the credential IDs locally. Server only has to send a challenge
5. If they clear local storage, go to a new browser etc, they need to sign-in "old school" again, after sign-in their registered credential IDs are saved in browser local storage again, ready for future WebAuthn sign-in

Good enough for my context, better than having the server responds with credential IDs based on a provided username alone.

Hope this makes sense enough.



Philipp Junghannß

Nov 10, 2022, 1:07:18 AM11/10/22
to Otto Kruse, FIDO Dev (fido-dev),, Tim Cappalli

Please don't get me wrong but imo this seems a bit backwards as the entire point of having FIDO2 and webauthn is eliminating passwords being sent to the website at all isn't it, I mean you still have a "pin" (which in fact can be a password, lol) as part of UV but that never gets transmitted to the website for the obvious reasons and not having sites need to deal with password storage is a good thing in the end as your pin practically couldn't leak apart from someone taking apart your FIDO device.

Discoverable credentials is just a new name for resident keys, the point is that the server does not need to provide the credential id for the authenticator to sort out the keys and all to perform the login.
The primary difference tho is obviously that Passkeys likely do not have a practically relevant storage limitation, as they are not only cloud synced but likely also not directly stored in the secure element but rather encrypted or whatever using a key on the secure element, and then throwing the actual passkeys onto the normal storage with the advantage of having A LOT more space for these things.

also a site currently cannot dictate to go resident on passkeys only and use a server-side credential for roaming authenticators instead without having separate registration flows (and obviously unless you want to ask the user to always enter their username even on passkeys, you also need to have 2 different login flows)

Reply all
Reply to author
0 new messages