From 5c33b6edf44611d2b8f1e3e95eb9a59fb62bf629 Mon Sep 17 00:00:00 2001 From: Emil Lundberg Date: Mon, 13 Aug 2018 15:08:44 +0200 Subject: [PATCH] Add Username Enumeration section to privacy considerations --- index.bs | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/index.bs b/index.bs index c93ce4896..d5691705e 100644 --- a/index.bs +++ b/index.bs @@ -3266,7 +3266,13 @@ the [=authenticator=] MUST: # [=[WRP]=] Operations # {#rp-operations} -Upon successful execution of {{CredentialsContainer/create()}} or {{CredentialsContainer/get()}}, the [=[WRP]=]'s script receives +A [=registration=] or [=authentication=] [=ceremony=] begins with the [=[WRP]=] creating a {{PublicKeyCredentialCreationOptions}} +or {{PublicKeyCredentialRequestOptions}} object |request|, respectively, which encodes the parameters for the [=ceremony=]. Most +importantly, |request| contains a random challenge and optionally a list of [=credential IDs=] eligible for the [=ceremony=]. The +[=[RP]=] SHOULD take care to not leak sensitive information while generating |request|; see [[#sctn-username-enumeration]] for +details. + +Upon successful execution of {{CredentialsContainer/create()}} or {{CredentialsContainer/get()}}, the [=[RP]=]'s script receives a {{PublicKeyCredential}} containing an {{AuthenticatorAttestationResponse}} or {{AuthenticatorAssertionResponse}} structure, respectively, from the client. It must then deliver the contents of this structure to the [=[RP]=] server, using methods outside the scope of this specification. This section describes the operations that the [=[RP]=] must perform upon receipt of these @@ -5401,6 +5407,41 @@ authenticator=] and [=client device=] SHOULD work together to ensure that the ex only to the operating system user that created that [=platform credential=]. +## Username Enumeration ## {#sctn-username-enumeration} + +While initiating a [=registration=] or [=authentication=] [=ceremony=], there is a risk that the [=[WRP]=] might leak sensitive +information about its registered users. For example, if a [=[RP]=] uses e-mail addresses as usernames and a user attempts to +initiate an [=authentication=] [=ceremony=] for "alex.p.mueller@example.com" and the [=[RP]=] responds with a failure, but then +successfully initiates an [=authentication ceremony=] for "j.doe@example.com", then the user can conclude that "j.doe@example.com" +is registered and "alex.p.mueller@example.com" is not. The [=[RP]=] has thus leaked the possibly sensitive information that +"j.doe@example.com" has an account at this [=[RP]=]. + +The following is a non-normative, non-exhaustive list of measures the [=[RP]=] MAY implement to mitigate or prevent information +leak due to such an attack: + +- When initiating an [=authentication ceremony=], generate and return a valid {{PublicKeyCredentialRequestOptions}} object + even if the supplied username is not registered. The {{PublicKeyCredentialRequestOptions/allowCredentials}} member may be + populated with random values. + +- When verifying an {{AuthenticatorAssertionResponse}} response from the [=authenticator=], make it indistinguishable whether + verification failed because the signature is invalid or because no such user or credential is registered. + +- If the [=[RP]=] uses [=[RP]=]-specific usernames as user identifiers: + + - When initiating a [=registration ceremony=], disallow registration of usernames that are valid e-mail addresses. + +- If the [=[RP]=] uses e-mail addresses as user identifiers: + + - When initiating a [=registration ceremony=], interrupt the user interaction after receiving the e-mail address to register + and send a message to this address, containing an unpredictable one-time code and instructions for how to use it to + proceed with the ceremony. Display the same message to the user in the web interface regardless of the contents of the + sent e-mail and whether or not this e-mail was already registered. + +- The preceding suggestion can be similarly adapted for other externally meaningful identifiers — for example, national ID + numbers or credit card numbers — if they provide similar out-of-band contact information — for example, + conventional postal address. + + # Acknowledgements # {#acknowledgements} We thank the following people for their reviews of, and contributions to, this specification: Yuriy Ackermann,