Clarity on challenge length

[sbweeden]

In an examples 1, 3 and 4 in section 1 there is a comment associated with the challenge:

/* 29 more random bytes generated by the server */

This intimates the "example" challenge is 32 bytes long, since 3 bytes are shown already in the example.

In the security considerations section we say:

In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible. Challenges SHOULD therefore be at least 16 bytes long.

Also in the appidExclude extension processing the challenge sent to the authenticator is described discretely as 32 random bytes. What would happen if the challenge provided by the RP was shorter, or longer, than this?

I think we should at least define a max challenege length, and potentially a recommended length (which should probably be the max).

[Firstyear]

I agree, but a minimum length would also be a good boundary rather than just recommending something. I've seen production deployments with challenges far shorter than 16 bytes that really should not be accepted.

So can we have a min and max bound?

[emlun]

Duplicate of #1115. Length alone is necessary but far from sufficient to make a secure challenge. I'm not sure that enforcing a min/max length helps more than it hurts - it could easily be misinterpreted to mean you're good as soon as you don't get an error message from the browser.

[Firstyear]

Correct, length is not enough but it is still an important factor. You can have a 2 byte challenge from the purest entropy money can buy, and that would be insufficient. You do need a minimum length, and there are production deployments that don't even meet the specifications recommendations today. Constraints are an important element in human interaction psychology, because without them people will make mistakes that have consequences. Introducing a minimum length constraint is good because it guides people to do the right thing.

[sbweeden]

Closing as spec changes are not going to really help here.