search

appdefensealliance / ASA-WG

1 stars 4 forks source link

1.4.3 Out of band verifier shall be securely random is not sufficiently defined #6

Closed mikewhiteman closed 1 week ago

mikewhiteman commented 4 weeks ago

Issue We need to define what securely random means in the context of out-of-band verifiers. In relation to our app ecosystem, we discussed the most common out-of-band verifier scenario likely being password reset emails. Given that we're allowing a max 7 day TTL for these out of band verifiers, we need a requirement that ensures verifiers are resistant to brute force attacks.

Recommendation I'll take a look at ASVS and similar guidance but we likely need to specify either a specific entropy requirement or a requirement that it should not be realistically brute forceable within the verifier's TTL.

johntidwell1 commented 3 weeks ago

Given that we're allowing a max 7 day TTL for these out of band verifiers, we need a requirement that ensures verifiers are resistant to brute force attacks.

NIST Guidance for Out-of-Band Verifiers identifies (for a 10 min validity time period) (https://pages.nist.gov/800-63-3/sp800-63b.html 5.1.3.2) a minimum at least 20 bits of entropy (~six digital random number), If the authentication secret has less than 64 bits of entropy (~20 digit random number), the verifier SHALL implement a rate-limiting mechanism.

I think something similar could work for us (especially with this as a reference). Also, wouldn't mind also coming down a bit on minimum complexity before a rate-limit is required.

Example: If minimum complexity of 2^44 per week (13 digits) of validity for the code, at ~10 million requests/second it would take ~10 days to traverse half the space.