Re: [webauthn] Clarify the need for truly randomly generated challenges (#1856)

Perhaps "replay attack" is too narrow a term. The purpose of "replay protection" is not only to prevent a challenge from being used more than once - rather, the more accurate underlying motivation is that a challenge-response protocol should ensure that the response was created _in response to_ the challenge. An unpredictable challenge establishes a temporal guarantee that the response was freshly created on request, and thus that the subject is _currently_ in possession of the signing key. If the challenge can be known beforehand, then there is no such guarantee as the response could have been created far in advance.

As a practical example, say you (an attacker) have access to a victim's security key for a short window of time - maybe you broke into their hotel room, or "borrowed" it from their desk while they were on the toilet. If the target RP uses predictable challenges - say, a timestamp or an incrementing counter - you can have the security key pre-generate a large amount of assertion signatures ahead of time and still use them after returning the security key. (The signature counter may defeat this if the RP verifies it, but only after the next time the victim uses the security key - and current RP implementations only rarely ask for the security key.)

So yes, you do need to "maintain a conception of current valid challenges". The easiest and least error-prone way to do so is likely to keep the state in server memory. But it is also possible to do with a stateless server, as long as you can protect the data from tampering. You could for example put the challenge and an expiration time in a [JWT](https://jwt.io/) or similar signed data structure stored on the client side. But note that this comes with its own set of issues, in particular in managing the signing key(s).

Would an edit like this make this clearer?

From:
>As a cryptographic protocol, Web Authentication is dependent upon randomized challenges to avoid replay attacks. Therefore, [...]

To:
>As a **cryptographic challenge-response protocol**, Web Authentication is dependent upon randomized challenges to avoid replay attacks **and verify current possession of the [credential private key](https://w3c.github.io/webauthn/#credential-private-key)**. Therefore, [...]

-- 
GitHub Notification of comment by emlun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1856#issuecomment-1437330597 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 20 February 2023 17:10:10 UTC