W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2020

Re: [webauthn] Dependence on Browser state for Primary Factor login (#1356)

From: Adam Langley via GitHub <sysbot+gh@w3.org>
Date: Wed, 15 Jan 2020 20:45:31 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-574848430-1579121130-sysbot+gh@w3.org>
> Unfortunately no as this still leaves the user in an error state until at least one valid credential is registered. It's also a bit of a jarring user experience for selecting a user. For our flow, platform authenticators are an upgrade after a traditional username/password login experience.

I think you are hitting issues because you're aiming for something outside the intended flows for WebAuthn. There are two typical flows envisioned:

1. The 2nd-factor case: user enters username + password. If correct, then a security-key challenge is an additional step and layer of security. Username enumeration is protected by needing to get the password right.
2. The 1st-factor case: user clicks a button to trigger a request with an empty allowList. Account is selected from an authenticator on the client and information returned to the web site. No user enumeration because there's no username.

From the above, I'm wondering whether you're trying something like: user enters a username, hits enter, gets security-key challenge. Issues with that:

1. It's single-factor: local proximity is sufficient. (Maybe that's ok.)
2. In high-value situations, it lets with an unknown security key ask "does this security key belong to suspect $x?" up to the rate limit of the web site.
3. It allows username enumeration, potentially.

The last point can be statistically ameliorated by having the server generate plausible, but random, credential IDs for any requested username by, e.g., HMACing the username with a server-side secret.

But, overall, that flow is not one that the WebAuthn design considers. The "1st-factor" flow is the intended answer there. Yep, it's possible that a user will click the button who hasn't actually enrolled a security key.

GitHub Notification of comment by agl
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1356#issuecomment-574848430 using your GitHub account
Received on Wednesday, 15 January 2020 20:45:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:39 UTC