Re: [webauthn] Should race condition be added as a reason for a signature counter not increasing? (#2172)

> 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.

Indeed. I was not trying to imply this was actionable; merely stating non-malicious reasons for this scenario to occur. That same sections states:

> Detecting a [signature counter](https://w3c.github.io/webauthn/#signature-counter) mismatch does not indicate whether the current operation was performed by a cloned authenticator or the original authenticator. [Relying Parties](https://w3c.github.io/webauthn/#relying-party) should address this situation appropriately relative to their individual situations, i.e., their risk tolerance.

so an RP may want to account for these legitimate reasons in their risk tolerance based on whatever probabilities they ascribe.

> It _might_ be doable with associating counter data with challenges (I think this is what you are getting at)

That is what I am getting at, and why I stated such a thing would only be possible for "second-factor" flows (i.e., more accurately, non-discoverable requests).

> but such an implementation may be highly error-prone and someone that has cloned an authenticator may be able to exploit this.

A careful RP could make this relatively error free. Depending on how the RP achieves this, a cloned authenticator could exploit this; however a "short" timeout makes this less of an issue.

> And even still, I think the appropriate thing to do is fail the ceremony, as you would have done previously.

Agreed. Again, I was not implying anything with this issue. I was merely pointing out "legitimate" reasons for a signature counter to not increase. As mentioned earlier, this is likely not actionable; therefore I would indeed fail the ceremony. All a user would have to do is re-try.
 
> 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.

Yep.

> 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.

With non-discoverable requests (i.e., relying on a non-empty `PublicKeyCredentialRequestOptions.allowCredentials`), the server has more information; so the following are a couple of ways an RP could combat this issue:

* Allow at most one active ceremony per Credential ID. This can be achieved several ways (e.g., a bit flag saved on the database which is using serializable transactions and perhaps additional exclusive locks to ensure a read does not occur while an update does). The RP only populates `allowCredentials` with the `PublicKeyCredentialDescriptor`s that aren't associated with an active ceremony. This is the most foolproof but comes at the cost of UX since users should be able to start concurrent ceremonies with the same Credential ID.
* As stated, the RP could associate the signature counter with the challenge/ceremony. The RP would allow a user to authenticate so long as the counter is larger than the counter at the time the ceremony started. Additionally the RP would not update the counter unless the saved counter is strictly less. Like you said, timeout duration is correlated with cloned authenticator risk.

-- 
GitHub Notification of comment by zacknewman
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2172#issuecomment-2387207769 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 22:38:36 UTC