Reconsider minimal length of passwords

[maizuka]

Hi,

I believe that the minimal length of passwords defined at 2.1.1 should be 8 characters rather than 12. Why not recover it?

Here are the reasons:

• Although the hashes from 8 chars can be reversed in a day, you need to have them locally. Brute-force attacks via network cannot be performed so rapidly.
• For local attacks against compromised hashes, the risks can be reduced using stretching as described in SP 800-63B.
• Limiting user passwords does not necessarily make them more secure, as indicated in the forbidding of composition, history and rotation requirements.
• As mentioned in Discussion: rules for password format and content #683, there are few web apps which meet the 12-chars requirement in real world. This might impact UX negatively and seems not to be employed in most of the apps, even 2 years after v4.0.1 released. I'm afraid that it may lower the reliability of ASVS as a standard.
• Although we can fork ASVS as a new checklist for each needs, it is too hard to extend password length because ASVS is considered as one of the significant baselines.

References:

• The pull request Password length proposed change #437 shows the evidence by hashcat and suggests of the change of this requirement from 8 to 12.
• The question Minimum Password Length #730 has the answer that we should fork ASVS to new standards if necessary.
• This answer is referenced against the push-back suggestion in the issue Discussion: rules for password format and content #683.

Regards,

Masahiro

[Sjord]

I agree. NIST says minimum of 8. Microsoft says minimum of 8, and longer is not necessarily better. OWASP says minimum of 8, in some places. The ASVS follows the NIST guidelines in almost everything, but not in this.

The PR that changed this from 8 to 12 did so, because 12 is 50% more than 8. That doesn't seem like a good motivation. It's not based on any research or anything. When a client asks why they should have passwords of 12 characters, I would like to have some better answer than 12 is 50% more than 8.

Another possibility to solve this issue is to don't give an exact value for the minimum length, and change the requirement to something like "Verify that user set passwords have a reasonable minimum length."

I also feel like ASVS wants to combine a verification standard with best practice recommendations. When designing an application, I would choose a certain minimum password length that is best practice and the most secure. When I am testing an application, a value that is not best-practice may still give acceptable security. I think ASVS should give limits for acceptable security, not for best security.

[jmanico]

NIST suggestions are way more nuanced. We are discussing SP800-63 here. For AAL 1 applications, NIST is suggesting 8 character passwords because it's only public data at AAL 1 For AAL 2 applications (serious sensitive data) NIST suggests at least 8 character passwords (that are not common or know plus a whole lot more pw controls) and multi factor that cannot only be SMS. IF you choose SMS for MFA you need to also provide another MFA method. For AAL 3 applications (critical infrastructure) you need 8 character passwords with a host of special controls plus a hard token for MFA. So "8 character passwords" per NIST is only relevant in the above context. - Jim

On 3/11/21 9:12 AM, Sjoerd Langkemper wrote: I agree. NIST says minimum of 8. Microsoft says <https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf> minimum of 8, and longer is not necessarily better. OWASP says <https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html> minimum of 8, in some places. The ASVS follows the NIST guidelines in almost everything, but not in this. The PR <#437> that changed this from 8 to 12 did so, because 12 is 50% more than 8. That doesn't seem like a good motivation. It's not based on any research or anything. When a client asks why they should have passwords of 12 characters, I would like to have some better answer than 12 is 50% more than 8. Another possibility to solve this issue is to don't give an exact value for the minimum length, and change the requirement to something like "Verify that user set passwords have a reasonable minimum length." I also feel like ASVS wants to combine a verification standard with best practice recommendations. When designing an application, I would choose a certain minimum password length that is best practice and the most secure. When I am testing an application, a value that is not best-practice may still give acceptable security. I think ASVS should give limits for acceptable security, not for best security. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#913 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCMYU5EKE4K7P2Q5GMLTDDFVHANCNFSM4ZAHCIIQ>.

-- Jim Manico Manicode Security https://www.manicode.com

[elarlang]

Few comments:

1. I think we should not take one password requirement out of context like this is the only requirement what matters and we should look entire set of rules for passwords, that is why I opened issue Discussion: rules for password format and content #683 ages ago.
2. Requirements like "Verify that user set passwords have a reasonable minimum length." does not have any point in my opinion. Those are still "Verify that your application is secure" and does not give any information and/or value.

[jmanico]

Elar, #683 Is a bit overwhelming but we will address is before the next major release. I agree with your point on #2 below. Aloha, -- Jim Manico @manicode

…

On Mar 11, 2021, at 9:59 AM, Elar Lang ***@***.***> wrote:  Few comments: I think we should not take one password requirement out of context like this is the only requirement what matters and we should look entire set of rules for passwords, that is why I opened issue #683 ages ago. Requirements like "Verify that user set passwords have a reasonable minimum length." does not have any point in my opinion. Those are still "Verify that your application is secure" and does not give any information and/or value. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jmanico]

Elar, Josh Grossman (out current process lead) was asking that you break issue 683 into smaller chunks, and rejected his request so we are likely to ignore 683 until you do as he politely asked. We need everyone to both be respectful and acknowledge the wishes of the ASVS leadership team in order to have a harmonious project.

…

-- Jim Manico @manicode

On Mar 11, 2021, at 10:03 AM, Jim Manico ***@***.***> wrote: Elar, #683 Is a bit overwhelming but we will address is before the next major release. I agree with your point on #2 below. Aloha, -- Jim Manico @manicode >> On Mar 11, 2021, at 9:59 AM, Elar Lang ***@***.***> wrote: >> >  > Few comments: > > I think we should not take one password requirement out of context like this is the only requirement what matters and we should look entire set of rules for passwords, that is why I opened issue #683 ages ago. > Requirements like "Verify that user set passwords have a reasonable minimum length." does not have any point in my opinion. Those are still "Verify that your application is secure" and does not give any information and/or value. > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or unsubscribe.

[elarlang]

What are you talking about? You describe this as problem or known rule which I broke. No, I said why it makes sense to have entire set of rules - to have clear overview. If there is time to PR's, I'll make them. But it requires some analytical feedback from others...

[maizuka]

Thank you for your comments.

It is true that NIST requires multi factor in AAL 2 and 3. However, it doesn't mean that the limit 8 is less secure or meaningless. It just indicates that single factor authentication is sufficient only for AAL 1.

To discuss about enriching beyond AAL 1, I suggest we should think about requiring MFA (2.2.4 at L3) in another issue, rather than about hardening password limits.

I've made this new issue because I felt that the #683 discusses more complicated points as overview and this 2.1.1 requirement has independent history and independent impact to user passwords.

I just want to improve ASVS standard and please excuse me if my words make some harm.

Regards

[jmanico]

It’s not a problem it’s just a request so we can work on the password issues in separate discussions since it’s a complex issue. 🤙🏼 This request came from Josh and it’s a reasonable one.

…

-- Jim Manico @manicode

On Mar 11, 2021, at 10:26 AM, Elar Lang ***@***.***> wrote:  What are you talking about? You describe this as problem or known rule which I broke. No, I said why it makes sense to have entire set of rules - to have clear overview. If there is time to PR's, I'll make them. But it requires some analytical feedback from others... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jmanico]

The point I’m making is - 8 character passwords alone is not enough for authentication when it comes for AAL 2 and above. I also agree with you there at 12 character password recommendation is very non-standard.

…

-- Jim Manico @manicode

On Mar 11, 2021, at 10:32 AM, IZUKA Masahiro ***@***.***> wrote:  Thank you for your comments. It is true that NIST requires multi factor in AAL 2 and 3. However, it doesn't mean that the limit 8 is less secure or meaningless. It just indicates that single factor authentication is sufficient only for AAL 1. To discuss about enriching beyond AAL 1, I suggest we should think about requiring MFA (2.2.4 at L3) in another issue, rather than about hardening password limits. I've made this new issue because I felt that the #683 discusses more complicated points as overview and this 2.1.1 requirement has independent history and independent impact to user passwords. I just want to improve ASVS standard and please excuse me if my words make some harm. Regards — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[jmanico]

No hard at all, I agree with your PR and we will address it before the next major release even if we do not have a full discussion right away. We often hold onto these comments and do not reply right away and when we’re getting close to a major release we address them in big batches when all the leaders are participating. :) Thank you! -- Jim Manico @manicode

…

On Mar 11, 2021, at 10:32 AM, IZUKA Masahiro ***@***.***> wrote:  Thank you for your comments. It is true that NIST requires multi factor in AAL 2 and 3. However, it doesn't mean that the limit 8 is less secure or meaningless. It just indicates that single factor authentication is sufficient only for AAL 1. To discuss about enriching beyond AAL 1, I suggest we should think about requiring MFA (2.2.4 at L3) in another issue, rather than about hardening password limits. I've made this new issue because I felt that the #683 discusses more complicated points as overview and this 2.1.1 requirement has independent history and independent impact to user passwords. I just want to improve ASVS standard and please excuse me if my words make some harm. Regards — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[tghosth]

Personally, the chart in the following tweet (from a couple of years ago) is what I think makes 12 char passwords so much better than 8 char passwords. Obviously an attack over the network will take longer but offline cracking is still a very valid scenario.

https://twitter.com/TerahashCorp/status/1155112559206383616/photo/1

[raoul361]

Could this not be linked through to an architecture question? I.e. whether a determination was made on what is appropriate for the particular use case (not forgetting whether this is appropriate also) and that the implementation follows? Obviously still requires a minimum baseline...

I'm also conscious that some user groups, particularly for large corporate/government sites, may have difficulty with long passwords. Thinking elderly/impaired users as possible issues here.

[jmanico]

None of the algorithms on this list are good password storage. bcrypt or Argon2id is the norm today for good password storage. https://tools.ietf.org/html/draft-ietf-kitten-password-storage-03 This is even more unnecessary in the face of multi factor AuthN which NIST 800-63 suggests for any application with sensitive data. I suggest 8 or if we want to push the limit, 10. But 12 does not seem reasonable, I state with respect. - Jim

…

On 3/11/21 4:33 PM, Josh Grossman wrote: Personally, the chart in the following tweet (from a couple of years ago) is what I think makes 12 char passwords so much better than 8 char passwords. Obviously an attack over the network will take longer but offline cracking is still a very valid scenario. https://twitter.com/TerahashCorp/status/1155112559206383616/photo/1 <https://twitter.com/TerahashCorp/status/1155112559206383616/photo/1> image <https://user-images.githubusercontent.com/13623828/110857804-f4a9cd80-82c1-11eb-9ea0-514cf97eab09.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#913 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCK2B4EECONFAEM4HTTTDEZJBANCNFSM4ZAHCIIQ>.

[Sjord]

the chart in the following tweet

This chart is accurate for random passwords, but does not account for user behaviour. The Microsoft document claims that users choose relatively easier passwords when a longer length is required:

Excessive length requirements (greater than about 10 characters) can result in user behavior that is
predictable and undesirable. For example, users who are required to have a 16-character password may
choose repeating patterns like fourfourfourfour or passwordpassword that meet the character length
requirement but are clearly not hard to guess. These passwords were chosen by participants in a pilot
study in which one treatment group was asked to create a password under the constraint that the
password must be 16 characters long.

[elarlang]

Why this requirement exists - it's for making offline guessing more resource-demanding for attacker. It's against brute-force attacks and there simple mathematics says that the longer a password is, it's more complicated and time-consuming to guess it.

If user chose "fourfourfourfour" with 16-character password requirement, I guess he/she chose "fourfour" for 8-character password. Simple passwords should be avoided with other requirements, like check against leakages and HIBP.

Those are just my thoughts on arguments provided here. Is the minimum length requirement 8 or 12, does not even matter too much. If authentication is done with only asking username and password, it's weak authentication anyway and should be considered as weakness already. If the main criteria to make application secure is length of password, then probably there are a lot of other things which need to be improved.

8-character passwords should be allowed ONLY when check from leakages, dictionaries etc are implemented.

[maizuka]

The PR to 8-chars limit has been approved and I close this issue. Thank you all for your comments and discussions.

I recognize there are remained discussions. I agree that password authentication is not secure until it meets ALL the related requirements of the corresponding level L1/L2/L3. It may needs additional requirements, e.g. about hashing process to mitigate offline attacks. And user set passwords have inevitable risks to the phishing or breached list attacks, which seem to be recently increasing, so MFA may be necessary even for L2 or L1 apps.

Regards

[tghosth]

I am going to re-open this issue because I would like to gather more feedback on this change. including from @vanderaj @m8urnett @demarinaGit.

The referenced Microsoft paper seems to be primarilly designed for Active Directory/Azure AD Administrators so I am not sure it is directly comparable and I am also not sure I understand exactly how the supporting research backed up a conclusion of a length of 8.

I think the main threat this particular requirement is coming to address is offline cracking and whilst I accept that password cracking is not random, if the full 8 character alphanumeric keyspace can be cracked in a space of months, even with a strong storage algorithm, I am not sure how much difference it makes.

[jmanico]

I totally support opening this back up. My argument for the merge is:

• 8 character passwords (alone) for authentication is only for public data per SP800-63.
• Anytime sensitive data is involved, multi-factor is REQUIRED. I suggest this as a level 1 requirement is so basic now.
• Anytime personal safety is involved (and more) than hard tokens are REQUIRED.

Password strength is not going to save you from phishing and other risks.

I also suggest ASVS updated password storage recommendations per https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html which was recently updated.

[tghosth]

Relevant thread:
https://twitter.com/CormacHerley/status/1379892615852613633?s=19

[jmanico]

1) I agree that marmite (and Vegemite) is horrible 2) I appreciate the other opinions around password length, I do think the change to 8 is acceptable but I’m still open to other opinions here

[vanderaj]

VEGEMITE IS THE BEST NECTAR OF THE YEAST GODS. Also, I would like us to keep in line with NIST 800-63 if at all possible. As someone who used to do GRC for his clients at KPMG, having multiple standards with multiple different requirements is a nightmare, and usually resulted in the worst common denominator being selected. Let's not let daylight come between us and NIST 800-63 if we can help it. It would be prudent to ask Jim Fenton, the primary author of NIST 800-63 if he's changed his mind at all on password length / complexity requirements before we change away from NIST. thanks Andrew

…

On Thu, Apr 8, 2021 at 7:28 AM Jim Manico ***@***.***> wrote: 1) I agree that marmite (and Vegemite) is horrible 2) I appreciate the other opinions around password length, I do think the change to 8 is acceptable but I’m still open to other opinions here — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#913 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGMA2JPAGVDIWOGVWNATQDTHWVO3ANCNFSM4ZAHCIIQ> .

[jmanico]

8 is the NIST standard, Andrew. We were the ones who deviated from it! But keep in mind that standard also mandates MFA anytime you have sensitive data in play. Respectful, Jim

[elarlang]

Keep minimal length 8 as it is now or back to 12 like it was before?

[tghosth]

@elarlang do we mandate MFA as a level 1 control?

[jmanico]

I say 2

…

-- Jim Manico @manicode Secure Coding Education +1 (808) 652-3805

On Jul 29, 2021, at 12:58 PM, Josh Grossman ***@***.***> wrote:  @elarlang do we mandate MFA as a level 1 control? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

[cmlh]

NTLM splits the password into two 7 character limits so the eighth character is easy to brute force as it is now a single character
password due to know padding.

I support a character length of 8 [characters] as per NIST 800-63 and this will not conflict with the UX.

I worked in emergency services and rejected hard tokens due to the high possibility that this would lead to loss of life if personal did not have their hard token at the time.

Also, this same high standard is not followed by vendors of hard tokens such as https://www.wired.com/story/the-full-story-of-the-stunning-rsa-hack-can-finally-be-told/ et al.

[elarlang]

I think this "level issue" must be clarified first - is it mostly "must be pentestable" or is it more "this application is not that critical".

MFA is pentestable, but I'm not that sure it must be required for "not that critical applications". Personally I don't mind, but I doubt it is realistic to require it. Yet.

[jmanico]

The original posters request on this thread is complete and live. I you have remaining topics you wish to discuss please open a new issue. :)

[cmlh]

Any chance of tagging the closed issue, as "Additional Issues", so it doesn't slip through the cracks?

[jmanico]

Good call Christian. Done. If you see other closed ones that have lingering issues, let me know...

[elarlang]

As this is "the most important requirement", then I just document it here - we don't apply this change to patch release (v4.0.3) as we consider it as breaking change.

• without having compensating requirements like required MFA, it weakens the requirement too much
• additional MFA requirement, like current 2.2.9 from bleeding edge is new requirement - which means breaking change for "patch release" and can not be included.

v4.0.2-2.1.1

Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined).

bleeding edge 2.1.1 (2021-10-27)

Verify that user set passwords are at least 8 characters in length.

bleeding edge 2.2.9 (2021-10-27)

Verify that a hardware-based authenticator and an authenticator that provides verifier impersonation resistance against phishing attacks are used, such as a multi-factor cryptographic hardware, or a combination of a single-factor cryptographic hardware and an OTP device.

[cmlh]

Should we have include roadmap explaining the adherence to NIST?