- From: Eric Stern via GitHub <sysbot+gh@w3.org>
- Date: Tue, 01 Oct 2024 21:34:51 +0000
- To: public-webauthn@w3.org
I see no immediate harm in pointing it out, but I'm not sure how actionable it would be for any of the involved parties. Trying to differentiate it from a cloned or malfunctioning authenticator could well be impossible. It _might_ be doable with associating counter data with challenges (I think this is what you are getting at) but such an implementation may be highly error-prone and someone that has cloned an authenticator may be able to exploit this. And even still, I think the appropriate thing to do is fail the ceremony, as you would have done previously. In your example, the majority case (outside of application bugs) user experience would likely be "my sign-in request is hanging so I'll try again", which would tend to result in the C1 request/response getting ignored or aborted by the client - though I suppose it could set off inappropriate some alarm bells on the RP side. > This primarily affects passkey flows and not second-factor ones; since for the latter, RPs can either force at most one active ceremony per credential or use the signCount at the time the ceremony began to compare to. Can you help me understand how this would differ in practice? For conditional flows, the fact that the request could have started minutes or even hours prior to response processing shouldn't have incremented the counter until the user actually approves the request (and if that's not the case, I'd argue the authenticator _is_ malfunctioning). I think this only creates problems if you're doing counter/challenge associations - effectively, trying to allow a counter rollback to go through under certain scenarios makes a common flow more likely to run into this problem in the first place. So after thinking it through a bit, my feeling is "this is unlikely enough that it's safe to omit", but "call it out but still recommend failing the ceremony" also seems fine to me. It's also completely possible I'm missing something obvious! -- GitHub Notification of comment by Firehed Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2172#issuecomment-2387117264 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 1 October 2024 21:34:52 UTC