Add security consideration on detecting non-WebAuthn accounts

index.bs

@@ -6562,6 +6562,27 @@ devices=].
 different [=public key credential|credentials=] are [=bound credential|bound=] to different [=authenticators=].
 
 
+### Unprotected account detection ### {#sctn-unprotected-account-detection}
+
+[INFORMATIVE]
+
+This security consideration applies to [=[RPS]=] that support [=authentication ceremonies=]
+with a non-[=list/empty=] {{PublicKeyCredentialRequestOptions/allowCredentials}} argument as the first authentication step.
+For example, if using authentication with [=server-side credentials=] as the first authentication step.
+
+In this case the {{PublicKeyCredentialRequestOptions/allowCredentials}} argument risks leaking information
+about which user accounts have WebAuthn credentials registered and which do not,
+which may be a signal of account protection strength.
+For example, say an attacker can initiate an [=authentication ceremony=] by providing only a username,
+and the [=[RP]=] responds with an empty {{PublicKeyCredentialRequestOptions/allowCredentials}} for some users
+and a non-empty {{PublicKeyCredentialRequestOptions/allowCredentials}} for other users.
+The attacker can then conclude that the former user accounts
+likely do not require a WebAuthn [=assertion=] for successful authentication,
+and thus focus an attack on those likely weaker accounts.
+
+This issue is similar to the one described in [[#sctn-username-enumeration]]
+and [[#sctn-credential-id-privacy-leak]], and can be mitigated in similar ways.
+
 
 # Privacy Considerations # {#sctn-privacy-considerations}
 
@@ -6806,8 +6827,8 @@ leakage due to such an attack:
         ceremony by invoking {{CredentialsContainer/get()|navigator.credentials.get()}} using a syntactically valid
         {{PublicKeyCredentialRequestOptions}} object that is populated with plausible imaginary values.
 
-        This approach could also be used to mitigate privacy leakage via {{PublicKeyCredentialRequestOptions/allowCredentials}};
-        see [[#sctn-credential-id-privacy-leak]].
+        This approach could also be used to mitigate information leakage via {{PublicKeyCredentialRequestOptions/allowCredentials}};
+        see [[#sctn-unprotected-account-detection]] and [[#sctn-credential-id-privacy-leak]].
 
         Note: The username may be "provided" in various [=[RP]=]-specific fashions: login form, session cookie, etc.