Spomky
commented
3 years ago Hi @BenjaminHae, Thank you for your patience.
I've registered one user test on the demo server. When trying to login with the user test2, the response to /api/login/options sends back an empty array for the key allowCredentials. However, the browser (chrome) still starts the authentication. The response to the challenge is then calculated using the key-pair for test. As a result I'm logged in as test, although no request to the server occurred that contains this username.
That's correct. When the username does not exist, the application generates a challenge and an empty list of credential. If you get authenticated with another username, this is because the browser has found credentials (resident key) and you are fully identified by the authenticator (PIN, fingerprint, facial recognation...). With simple touch-like authenticator, this behaviour is not possible. See this page for details.
I there should be a validation as to whether the response fits to the user specified - not only, whether there is a public-key in the server database.
On server side, the username is only used to retreive a list of credentials:
- If the list is empty, this means the user will be fully authenticated by the authenticator
- If the list has public key credentials, only one of these credentials shall be used On client side, you should normally see a popup on your browser telling you to choose the correct profile depending on the available/acceptable authenticators based on this list (and other parameters).
Additionally as a result, I believe the allowCredential key should be omitted in the options, as it's content might allow an unauthenticated user to find out which users exist on the server.
Yes and No. Yes because I am conviced that authentication without username is the most efficient and secured way to authenticate users. Nowaday, most authenticators supports at least PINs. With Windows Hello, Android devices and recently all Apple devices, you can easily use fingerprints or faces to enforce the authentication. No because if this list is empty, all other authenticators (old U2F devices, basic Yubico tokens and so on) won't be able to be used.
It is right to say that a non-empty list allows malicious application to establish a list of usernames. This is why it is not recommended to use e-mails as username (see https://webauthn-doc.spomky-labs.com/pre-requisites/user-entity-repository and https://www.w3.org/TR/webauthn-2/#sctn-username-enumeration).
With that being said, it seems like it is a good idea to add an option (firewall maybe) requiring an empty credential list. Another way I tried to implement was the use of fake users so that the list is always populated. I abandonned this way as it is not so easy to implement (requires cache to random credential IDs to be detected)
github-actions[bot]
I've registered one user
teston the demo server. When trying to login with the usertest2, the response to/api/login/optionssends back an empty array for the keyallowCredentials. However, the browser (chrome) still starts the authentication. The response to the challenge is then calculated using the key-pair fortest. As a result I'm logged in astest, although no request to the server occurred that contains this username.I there should be a validation as to whether the response fits to the user specified - not only, whether there is a public-key in the server database. Additionally as a result, I believe the
allowCredentialkey should be omitted in the options, as it's content might allow an unauthenticated user to find out which users exist on the server.