- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Sat, 25 Feb 2023 00:36:44 +0000
- To: public-webauthn@w3.org
> I am curious, are you saying that it would be acceptable for RPs to ignore actual replays so long as challenges are tightly time-bounded? The "can" there was in the spirit of "technically possible, and something that sites might do in practice". Time bounding does not fully prevent replays and is thus weaker. But time bounding also makes it a lot easier to fully prevent replays by limiting the amount of server-side state that needs to be kept. > It might also have value in the modal use case so that the platform dialog could take longer for things like just-in-time UV provisioning (including PIN), guided help, etc. I'm only proposing it for conditional UI requests: 1. Once the request has gone modal browsers have often passed things off to the operating system. Wiring a loop from there all the way back to the renderer is going to be a _lot_. 2. Just-in-time UV configuration is slow, but it happens when making a credential, and the challenge has completely different requirements there. (E.g. if you're not checking attestation it can be a fixed value. Even if you are checking, the security properties of freshness are very different.) 3. The time to complete the modal part of a getAssertion should be on the order of a couple of minutes and it should be reasonable for sites to keep server-side state for that amount of time and completely prevent replays. 4. The site can set the `timeout` on a modal getAssertion to enforce its limit and the user can get a reasonable error message and manually retry in the small fraction of cases that exceed that. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1856#issuecomment-1444808246 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 25 February 2023 00:36:46 UTC