[webauthn] How long the relying party should maintain the challenge and related information? (#1848)

Kieun has just created a new issue for https://github.com/w3c/webauthn:

== How long the relying party should maintain the challenge and related information? ==
In section [13.4.3. Cryptographic Challenges](https://w3c.github.io/webauthn/#sctn-cryptographic-challenges), there are some information about such requirements.
> As a cryptographic protocol, Web Authentication is dependent upon randomized challenges to avoid replay attacks. Therefore, the values of both [PublicKeyCredentialCreationOptions](https://w3c.github.io/webauthn/#dictdef-publickeycredentialcreationoptions).[challenge](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-challenge) and [PublicKeyCredentialRequestOptions](https://w3c.github.io/webauthn/#dictdef-publickeycredentialrequestoptions).[challenge](https://w3c.github.io/webauthn/#dom-publickeycredentialrequestoptions-challenge) MUST be randomly generated by [Relying Parties](https://w3c.github.io/webauthn/#relying-party) in an environment they trust (e.g., on the server-side), and the returned [challenge](https://w3c.github.io/webauthn/#dom-collectedclientdata-challenge) value in the client’s response MUST match what was generated. This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the [Relying Party](https://w3c.github.io/webauthn/#relying-party) SHOULD store the challenge temporarily until the operation is complete. Tolerating a mismatch will compromise the security of the protocol.

Following sentence is quite unclear to me.
> This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the [Relying Party](https://w3c.github.io/webauthn/#relying-party) SHOULD store the challenge temporarily until the operation is complete.

It seems that the RP server should have a kind of timeout to invalidate the challenge in order not to rely on the client's behavior.
RP might set some timeout values by considering the expected user action timeout and indicate such expectations in the options and our current implementation follows such behavior.

One of issues if the RP have similar logics, if the conditional UI (autofill) is used as follows.
1. User loads the login page (w/ conditional UI) and fetches the webauthn.get options.
2. User does not perform webauthn login process.  e.g., moves to other tabs and stays there until the server's challenge is timeout
3. User moves to the original tab and performs webauthn login with Auto-Fill UI
4. _User sees an error since the challenge on the RP server side is already timeout(or invalidated)_

**In above case, if the RP server does not have any timeout for the issued challenge, it would create some security risks.**

What's the recommendation of this? Or, is it better to respect preferred timeout value from the option in the browser' auto-fill implementation?


Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1848 using your GitHub account


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

Received on Friday, 3 February 2023 01:44:43 UTC