Non-incrementing signature counters could be due to race condition

[sbweeden]

Closes #2172

Includes observation that an RP processing order race condition may be a cause of non-incrementing signature counters during validation.

---

Preview | Diff

[zacknewman]

LGTM.

[MasterKale]

WebAuthn is a human-centric API with ceremony times long enough to prevent most race conditions related to counters not incrementing between responses. What types of RP use cases is this updated verbiage intended to address? I can only think of convoluted scenarios like "a single passkey used by multiple users across multiple kiosks not syncing counter state" that this might unblock. But otherwise why would we weaken the counter check like this?

[zacknewman]

What types of RP use cases is this updated verbiage intended to address? I can only think of convoluted scenarios like "a single passkey used by multiple users across multiple kiosks not syncing counter state" that this might unblock.

See the linked issue.

But otherwise why would we weaken the counter check like this?

Not sure I agree that this "weakens the counter check". No changes are made to the recommendation that an RP SHOULD fail the ceremony. This provides an example of a situation that RPs are welcome to ignore no differently than the possibility of a faulty authenticator which I don't believe "weakens" the counter check either.

An eager user can log in multiple devices using the same credential before the first ceremony is actually complete. The path data sent from one client takes may be encumbered with issues that data sent from another does not encounter allowing a "later" response to actually be received or at least processed before the "earlier" response.

[MasterKale]

We had a good talk about this at today's WG call. I've come around and think this is fine guidance to include in the spec (since it doesn't change anything about actual counter-related response verification logic)

[nsatragno]

What if the RP stores a snapshot of the counter of all authenticators for a user at the time a challenge is vended? That way you'd be able to compare the counter against the value at the time you requested an assertion.

[sbweeden]

What if the RP stores a snapshot of the counter of all authenticators for a user at the time a challenge is vended? That way you'd be able to compare the counter against the value at the time you requested an assertion.

That's a clever remediation, but the focus of this PR is simply to describe some possible causes for counter mismatch rather than suggest how an RP should deal with it.