Re: [webauthn] How to deal with discoverable credentials? (#1764)

> However, in the case of discoverable credentials, this association username <-> challenge does not yet exist. So what do you do? Do you maintain some giant pool of anonymous challenges to check from or what? After all, these challenges are there to avoid replay attacks.

Essentially, yes. If you already know the username before issuing the challenge, then you should of course verify that the response signed the correct challenge for that user. For username-less authentication with a discoverable credential you only really need to verify that the signed challenge was issued recently and hasn't already been used.

In my implementations I've associated each new challenge with a "request ID" which is sent to the client along with the challenge and returned to the server with the signed response. The server then looks up the request ID and removes it from the state map in memory, then verifies that the signed response matches the challenge that was stored for that request ID. This ensures that at most one authentication attempt is allowed for each challenge.

So to paraphrase your first post it's something like this:

```
Browser->Server: get challenge for ???
Server->Browser: here is challenge X
Browser->Server: here is a signed challenge X + payload for "john.doe@example.com"
Server: verifies challenge X exists in memory, signature valid, public key belongs to "john.doe@example.com", payload...
Server: (even if previous step failed) delete challenge X from memory
```

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1764#issuecomment-1176239439 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 July 2022 13:43:24 UTC