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

manger has just created a new issue for https://github.com/w3c/webauthn:

== Privacy risk from revealing allowed credentials ==
A relying party wanting to use WebAuthn Authenticators (including those with non-resident keys) as a 1st factor needs to prompt for a username (eg email address) then reveal that user's credential ids by listing them in the allowedCredentials argument to the navigator.credentials.get() call. Hence, a user's credential ids are revealed to anyone who enters their username.

This is not a security problem (revealing a credential id does not allow anyone to authenticate with that credential). But it might be a slight privacy issue: it reveals how many authenticators a user has registered with this RP; and the length of each credential id gives a hint about its type. While the credential ids for the same user at another RP will have different values, it is likely that there will be the same number and they will have the same length.

[ยง13.10 Username Enumeration](https://w3c.github.io/webauthn/#sctn-username-enumeration) already suggests an RP return a fake credential id when it has no account for a given username (see [issue 1014](https://github.com/w3c/webauthn/issues/1014)). But RPs may not do that as many don't bother preventing username enumeration.

An RP could include fake credential ids alongside the real credential ids in the allowedCredentials argument (eg so everyone appears to have, say, 10 authenticators). That should be able to address most of the privacy risk (if the fakes are carefully chosen).

Is this worth mentioning in the Privacy Considerations section?
Could extra fake credentials harm the WebAuthn experience (either affecting the user interface, slowing performance, or causing errors)?

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1246 using your GitHub account

Received on Thursday, 27 June 2019 08:30:42 UTC