Entropy requirements vs. length requirements

[suvikaartinen]

Some requirements set character length requirements, some set entropy requirements, some both. Concept of entropy is probably not clear for many people, but number of characters can be very misleading especially when we talk about human generated strings that tend to use patterns (such as starting with big letter and ending with number), which significantly lowers the amount of entropy. Eight random character would probably create enough entropy, but passwords are not even near to random. Maybe most accurate formulation would be to use the format of 2.7.6 where entropy requirement is set together with an example: Verify that user password contain at least 64 bits of entropy, e.g. 10 random ascii character or 5 random words (ref. https://en.wikipedia.org/wiki/Password_strength)

https://github.com/OWASP/ASVS/blob/master/5.0/en/0x11-V2-Authentication.md#v21-password-security

2.1.1 [MODIFIED] Verify that user set passwords are at least 8 characters in length.

https://github.com/OWASP/ASVS/blob/master/5.0/en/0x11-V2-Authentication.md#v26-look-up-secret-verifier

2.6.2 [MODIFIED] Verify that lookup secrets have sufficient randomness (112 bits of entropy), or if less than 112 bits of entropy, are hashed with an approved password storage hashing algorithm.

https://github.com/OWASP/ASVS/blob/master/5.0/en/0x11-V2-Authentication.md#v27-out-of-band-verifier

2.7.6 Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically a six digital random number is sufficient).

[tghosth]

Can you suggest how you would reword the requirements?

[suvikaartinen]

How about scoping the entropy requirement for different levels: Verify that user set password contain at least 40/64/80 bits of entropy (e.g. 8/10/13 random characters or 4/5/7 random words).

I am also tempted to add the requirement that amount should be doubled, if MFA is not in use.

[tghosth]

I don't want to mess with the actual password length which has already been discussed a lot here: https://github.com/OWASP/ASVS/issues/913

Please can you propose how you would clarify the existing the requirements to include the actual entropy required?

[luissaiz]

https://pages.nist.gov/800-63-3/sp800-63b.html#memsecret

"Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets."

"A.5 Summary Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive. Furthermore, other mitigations such as blacklists, secure hashed storage, and rate limiting are more effective at preventing modern brute-force attacks. Therefore, no additional complexity requirements are imposed."

[tghosth]

@suvikaartinen I agree that there is inconsistency where sometimes it gives a length and sometimes it gives an entropy. Could you suggest updated wording for the various requirements which includes both?

[Sjord]

Some requirements are given as length, others as entropy. I don't think this is a problem, or inconsistent.

It is possible to reason about the entropy of random secrets that the application generates. We take 14 bits from the CSPRNG, base64-encode it, and have a token with 14 bits of entropy, and this is insufficient.

It is harder to reason about password entropy. This is created by the user, and it is hard for the application to determine the entropy of their password. It is also hard to indicate to the user that their password should have 40-bits of entropy. It's much easier that it has to be at least 8 characters.

In the past, we more or less required more entropy in passwords by requiring "special characters", or capitals, letters, punctuation. This turned out to be ineffective, because it does not make users create random passwords, they just put a exclamation mark at the end.

Users are shit at making up passwords, and they work really hard to stay shit at it. When thinking about password security, one must also think about user behavior. Increasing the password limit from 8 characters to 12 characters does not give 150% security. Users will just put "1234" at the end of their usual password.

Smarter people than us thought about the best password rules, also taking user behavior into account. Perhaps counterintuitively, this resulted in a password length of at least 8 characters instead of anything longer. But these password rules are part of a set of security rules, such as brute-force protection, MFA, checking against breached passwords, etc.

[tghosth]

So my inclination is to close this unless @suvikaartinen has further suggestions for updated wording

[suvikaartinen]

My proposal:

2.1.1 Verify that user set passwords have at least 40 bits of entropy (typically 8 random characters or 4 random words is sufficient).

2.6.2 Verify that lookup secrets have at least 112 bits of entropy (typically 34 random numbers is sufficient), or if less than 112 bits of entropy, are hashed with an approved password storage hashing algorithm.

2.7.6 Verify that the initial authentication code is generated by a secure random number generator, containing at least 20 bits of entropy (typically six random numbers is sufficient).

[tghosth]

Thanks @suvikaartinen, please can you confirm that those requirements are worded as similarly as possible to the current requirements in the 5.0 folder?

@elarlang @Sjord what do you think about that proposal?

[Sjord]

I would leave it as it currently is, and don't agree with @suvikaartinen's proposal. I attempted to explain why in this comment. Most importantly, I don't see it as a problem or even as an inconsistency that we sometimes specify length and sometimes entropy. I think it makes sense to require length for passwords, and I don't think it makes sense to require entropy. An minimum entropy for user-chosen passwords would not be enforcable by the application.

[tghosth]

@elarlang what do you think?

[elarlang]

2.1.1 in proposed wording requires "translation", I think current one is better. For others I don't have strong opinion.

[tghosth]

Hi @suvikaartinen,

Thanks for your efforts on this. Having dug into it a little more, my inclination would be to leave the actual requirements as they because they map to specific requirements within NIST. On the other hand, I think that the entropy concept is a little confusing and I think maybe we should have a note before or after section 2.6 that explains a little more about how to convert the entropy into real character values.

Would you feel comfortable creating a draft of what that note would say?

For future reference:

• Formula for calculating password entropy
• Example of doing this in Wolfram Alpha for an 8 character password using upper, lower and digits

[suvikaartinen]

Sorry for slowness in answers, apparently I have way too much customer work to really give proper effort on this. From my perspective the formula for calculating password entropy give all the needed details, but it might be just me (as I have a math background): Entropy is calculated as the base-2 logarithm of the total number of different lookup secrets/authentication codes. For example entropy of 6-digit authentication code, consisting of numbers (10 options) is calculated by taking calculating log_2(10^6).

[tghosth]

@set-reminder 1 week look a this

[octo-reminder[bot]]

⏰ Reminder Wednesday, December 14, 2022 12:00 AM (GMT+01:00)

look a this

[Sjord]

The answers to What is the best way to calculate true password entropy for human created passwords? - Information Security Stack Exchange give some reasons why it's not so simple to compute the entropy of a password, or even whether it makes sense to say passwords have entropy.

[tghosth]

Ok so I am convinced that this is not ideal for passwords.

@Sjord do you have any objections to the following?

2.6.2 [MODIFIED] Verify that lookup secrets have at least 112 bits of entropy (typically 19 random alphanumeric characters or 34 random numbers is sufficient) and are hashed with an approved password storage hashing algorithm. If there are less than 112 bits of entropy then a 32bit random salt should be incorporated.

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 six random numbers is sufficient).

I also made some fixes to 2.6.2 to be more in line with NIST

[octo-reminder[bot]]

🔔 @tghosth

look a this

[Sjord]

Verify that lookup secrets have at least 112 bits of entropy

NIST says:

Look-up secrets SHALL have at least 20 bits of entropy.

...

Look-up secrets having at least 112 bits of entropy SHALL be hashed with an approved one-way function as described in Section 5.1.1.2. Look-up secrets with fewer than 112 bits of entropy SHALL be salted and hashed using a suitable one-way key derivation function, also described in Section 5.1.1.2. The salt value SHALL be at least 32 in bits in length and arbitrarily chosen so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each look-up secret.

I think this means that look-up secrets are allowed to have less than 112 bits of entropy, but should have at least 20.

2.7.6 already contains "typically a six digital random number is sufficient". I don't think this needs to be changed.

123456 is one number containing six digits. So saying "six random numbers" is inaccurate.

[tghosth]

My head hurts... 🤦‍♂️🙂 Ok so focusing on 2.6.2, I think we need to split this requirement out to be less complicated:

2.6.2 [MODIFIED] Verify that lookup secrets with 112 bits of entropy or more (typically 19 random alphanumeric characters or 34 random numbers is sufficient) are hashed with an approved password storage hashing algorithm. If the secret has less than 112 bits of entropy, then a 32bit random salt should be incorporated.

2.6.4 [ADDED] Verify that lookup secrets have a minimum of 20 bits of entropy (typically 4 random alphanumeric characters or 6 random numbers is sufficient).

For 2.7.6, I think it stays as it is. 123456 is probably not a random number :)

[Sjord]

123456 is one number containing six digits

123456 is probably not a random number :)

The point was the distinction of definition between the words "number" and "digit". You suggest "6 random numbers", but it seems you mean 1 random number consisting of 6 digits.

[elarlang]

Josh, in case 2.6.4 is not completely new and is split from 2.6.2, please use label [MODIFIED, SPLIT TO 2.6.4] for 2.6.2 and label [ADDED, SPLIT FROM 2.6.2] for 2.6.4

[tghosth]

@Sjord haha, fair one.

@elarlang I don't think we actually mentioned this part before even though it is mentioned in NIST

@elarlang @Sjord would appreciate your review on #1449

[tghosth]

@elarlang @Sjord reminder that I would appreciate your review on #1449.

i also clarified 2.6.2 based on @jimfenton's comments in #1477