Re: [webauthn] Privacy risk from revealing allowed credentials (#1246)

> Sorry to ping such an old thread, but I'd like to ask some questions to get a current-state feeling on the topic:
> 
>     1. Do those of you participants in this thread _still_ feel that the disclosure concern isn't much of an issue because webauthn isn't really being used as a primary auth factor? I ask because I am building sites (multiple!) that do in fact use it as primary, but I am just wondering if those in charge of things still feel like that's rare or not really the direction this stuff will go?

Webauthn is a primary auth factor. It is what underpins Passkeys and Passwordless authentication flows. 

> 
>     2. On this use-case (again, for primary auth) where a user might have multiple credentials (across different devices, for example) tied to their username/email, but some or all of these might not be discoverable (due to user choices and/or authenticator limitations, not just RP settings), and as such the user has to input their account identifier to get back from the RP the list of their credentials...
>        Have you considered the specific disclosure vector which is that such an endpoint faces an uncomfortable fact that even if they are generating fake credentials for unknown accounts, the count of those fake credentials created, at a minimum oracle signals information to an attacker?
>        Like, for example, if an attacker inputs _known fake_ account identifiers (made up emails), and they do a lot of those and always get back a single fake credential, yet the attacker observes that some other expected-valid accounts return 2+ credentials... this count/distribution differential is itself a disclosure vector.
>        One possible mitigation might be to have the endpoint deterministically decide (like from secret hash bytes) to send 1-3 fake credentials, even with deterministically varying the `transports` list per credential. But whatever cap (3, 4, etc) that's used for this count, if any user's account has more than that to return, then even one such return for an attacker confirms that _this_ was much more likely a _real_ account.
>        But for UX purposes, it's impractical/unworkable to just generally cap real users' credentials count, so it means this endpoint either has to ignore this disclosure vector, or unboundedly generate larger sets of fake data based on the largest number of real credentials on any account.
>        AND... the larger that count, the more the opposite becomes true, if statistically most accounts only have 1 or 2, but the endpoint is often returning 3, 4, or even 5 credentials for known fake accounts, then an attacker can clearly see the pattern and get more info.
> 
> 
> My point is, it seems like this is a clear case of security vs UX in a way that seems intractable. Do you have any thoughts on that, or other ways of thinking about the problem space?


As the creator of the novel approach to return fake credential id's, we did analysis to determine how and what to return. You can see a complete write up here:

https://github.com/kanidm/webauthn-rs/blob/master/webauthn-rs-core/src/fake.rs

It is worth noting that this approach is needed if and only if you provide Passwordless flows (non-resident key, non-discoverable credentials). If you perform "Passkey" flows with resident keys/discoverable there is no need to disclose the credential ID's from the RP, meaning that this "fake" credential ID generator is not required. This is because the Passkey itself provides the user identifier in the assertion, such that you don't need to enter a username field or receive a list of credential ID's to initiate the flow. 

In addition, this technique is only needed if there is a significant privacy risk associated with the IDP, and that knowledge of someone holding an account may cause harm to those persons. In most cases, knowledge that an account exists with some identifier is not a concern, and this mitigation is not required. 

-- 
GitHub Notification of comment by Firstyear
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1246#issuecomment-3677103621 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 20 December 2025 00:51:33 UTC