Closed sbweeden closed 4 weeks ago
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.
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.
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.
Closes #2172
Includes observation that an RP processing order race condition may be a cause of non-incrementing signature counters during validation.
Preview | Diff