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

dolda2000 has just created a new issue for https://github.com/w3c/webauthn:

== Clarify the need for truly randomly generated challenges ==
## Proposed Change

The current standard says, with regards to challenge strings, that their main use is to "avoid replay attacks", which certainly agrees with my layman understanding of cryptography. It does on, however, to conclude that this means that challenges...

> MUST be randomly generated by Relying Parties in an environment they trust [...] and the returned challenge value in the client’s response MUST match what was generated

... which does not agree with my layman understanding of cryptography.

If avoiding replay attacks is the *only* purpose of the challenge, then, at least according to my layman understanding of cryptography, that would mean that the only requirement would be preventing the same challenge from being used twice, not that it needs to be cryptographically random. The standard goes on to state that...

>In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible.

... and unless my layman understanding of cryptography is lacking, this is not correct. Guessing a challenge in advance, or being able to use a challenge that has not strictly been pre-generated by the server should not be a problem in preventing replay attacks.

On the other hand, requiring the challenge to be cryptographically securely generated on the server implies quite a number of restrictions on the implementation, not least the need to statefully maintain a conception of current valid challenges. In fact, I am currently considering a challenge maintenance protocol that would be stateless, in order to avoid the need to create web sessions for clients that merely visit a login page and trigger a conditional mediation flow that they quite likely never utilize, and also to avoid potential DoS attacks from spamming the challenge generator, generating an unbounded number of sessions only limited by the rate at which they can be requested.

For this reason, if there actually does exist a need to generate cryptographically random challenges in a trusted environment, I would appreciate that this need be clarified. Otherwise, I think the specification should be updated to reflect that the requirement is to prevent challenges from being used more than once, rather than being unguessable.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1856 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 15:07:09 UTC