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?

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 creates, 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 user's 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?

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


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

Received on Friday, 19 December 2025 21:21:01 UTC