- From: Fredrik Tolf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Feb 2023 20:05:13 +0000
- To: public-webauthn@w3.org
@emlun >Agreed, but you can work around this by periodically refreshing the challenge and using an abort signal to cancel the timed-out conditional WebAuthn request and restart it with the new challenge. Hm. I understand this is an option, but if that is how conditional mediation should/must work, then some clarification really does seem to be in order, since the references I quoted above are from pretty big names in the WebAuthn/Passkey community, and all of them seem to be implying that long-lived challenges are the intended solution (at least that's what I personally gathered from them). I will add, however, that I also also posted #1854 recently, about the greater-than-perhaps-expected complexity of using modal and conditional mediation on the same page, and having a timed loop restarting a conditional mediation periodically doesn't exactly improve that situation. Don't get me wrong, I'm sure it's implementable and all, it just seems like a fair bit of complexity for what seems to be intended to be a pretty standard thing to do. I also suggested in passing in #1848 that it would probably be nicer if conditional mediation were a two-stage process where the browser effectively requests the full challenge information from the page if and when the user actually decides to start using WebAuthn. As I mentioned therein, I understand more than well that it might be difficult to change at this point, but especially if it is a security concern to have challenges be as short-lived as possible, I can't help but think that that strengthens the case. >This could make for a poor UX if the user happens to be interacting with the conditional UI right then, but that seems fairly unlikely to me. If the expected challenge lifetime is on the order of 15 minutes, then assuming an average interaction takes some 5-10 seconds or so, that's about a one-in-a-hundred chance of that happening. Not the end of the world by any means, but still high enough that it starts to border on slightly unelegant. Not to toot my own horn, but the two-stage process mentioned above would fix the issue. --- @arianvp What I currently plan on doing is to include the value of a monotonically increasing challenge counter in the challenge token, and then keep, per account, a list of the counters of the `$SOMENUMBER` last challenges, along with a record of the highest counter value expunged from that list, and then reject challenges that are either in the list, or have a counter value <= the highest-expunged value. Unless there's something I'm not thinking through properly, I believe that fixes the "use-exactly-once" problem (with O(1) storage requirements). -- GitHub Notification of comment by dolda2000 Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1856#issuecomment-1439027536 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 February 2023 20:05:15 UTC