2.7.6 and 2.7.7 are in conflict

[jmanico]

One suggests 20 bits

2.7.6	[MODIFIED] Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient).

Another suggests 64 bits

2.7.7	[ADDED] Verify that the initial authentication code is protected against brute force attacks by using either rate limiting or a code with at least 64 bits of entropy.

[Sjord]

2.7.7 says to use rate limiting if the authentication code is less than 64 bits.

NIST says:

The verifier SHALL generate random authentication secrets with at least 20 bits of entropy using an approved random bit generator [SP 800-90Ar1]. If the authentication secret has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

[elarlang]

"use rate limiting if the authentication code is less than 64 bits".

Like you should not use rate limiting by default... it's confusing.

[elarlang]

The requirement 2.7.7 got in via 401fe46 from issue #1410 (comment)

I assigned this issue to @tghosth as the author of 2.7.7 (#1410) and @jmanico as the author of this issue.

[aholmis]

I don't think they are in conflict, they are additive.
2.7.6 is about a general minimum entropy when generating the code
2.7.7 is about brute force protection of the code validation

[elarlang]

My vision is, that there should be rate-limiting anyway and always used. What could be the reason do not have it?

It means, for me 2.7.7 is in a way duplicate of rate-limiting requirements, such as:

• V2.2.1 [MODIFIED] Verify that anti-automation controls are effective at mitigating breached credential testing, brute force, and account lockout attacks. ...
• V11.2.2 [MODIFIED, MOVED FROM 11.1.4] Verify that the application has anti-automation controls to protect against excessive calls to application functionality which could result in mass data exfiltration, junk data creation, resource quota exhaustion, rate limit breaches, out-of-band communication flooding, denial of service, overuse of an expensive resource, etc.

Maybe we can merge 2.7.7 to 2.2.1 or to 11.2.2.

Rest of the 2.7.7 can be considered as duplicate of 2.7.6, if there is a need to increase the entropy, it can be done with 2.7.6.

[tghosth]

@aholmis is correct, this is is how we have interpreted the NIST requirements.

The duplication thing is a tricky question. I think we need a way of having a blanket rate-limiting requirement or at least just one covering authentication flows. I would punt this to V2 rework.