Discussion: rules for password format and content

[elarlang]

By rules, how weak can be password

And if someone says weak, then... weak against what?

Weak against brute force

V2.1.1 Verify that user set passwords are at least 12 characters in length.

and

V2.1.9 Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.

By current rules, ASVS v4 accepts password with only numbers and 12 symbols long.
It's about the same strong as capital-letter + lower-case letters + numbers and 7 symbols long.

combinations	pattern	min length
1028071702528	[A-Za-z0-9]	7
1111111111110	[0-9]	12
2821109907456	[a-z0-9]	8
5429503678976	[a-z]	9
53459728531456	[A-Za-z0-9]	8

I think requirement V2.1.9 needs some modification. Only numbers are not ok. Can not really write this kind of recommendation to pen-test report.

Weak against dictionary attacks

V2.1.7 Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. ...

In theory, it should keep passwords okeish against dictionary attacks.

I personally miss one more requirement, with meaning (but not given wording):

User must avoid simple-stupid-predictable-passwords, like:

• password can not contain user data (name, email, company, whatever is provided to application/site)
• password can not contain application/site name

Using personal data or site name as password is widespread behavior and this kind of weak passwords give more realistic attack vector (online dictionary attacks) compared to offline (how you got hashes!?) brute force or using massive breach data sets.

[elarlang]

Well, I dig to it more deeply.

Password change functionality

Current:

• V2.1.5 Verify users can change their password.
• V2.1.6 Verify that password change functionality requires the user's current and new password.
• V2.1.10 Verify that there are no periodic credential rotation or password history requirements.

Recommendations:

• Recommendation no 1: Split V2.1.10 to 2 different requirements. First part is for functionality, second part for password content.
  • moved to issue Discussion/Proposal: split 2.1.10 to 2 separate requirements #940

Password format (min length, max length, allowed characters)

Current:

• V2.1.1 Verify that user set passwords are at least 12 characters in length.
• V2.1.2 Verify that passwords 64 characters or longer are permitted.
• V2.1.3 Verify that passwords can contain spaces and truncation is not performed. Consecutive multiple spaces MAY optionally be coalesced.
• V2.1.4 Verify that Unicode characters are permitted in passwords. A single Unicode code point is considered a character, so 12 emoji or 64 kanji characters should be valid and permitted.
• V2.1.9 Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters.

Recommendations:

• Recommendation no 2: add requirement, that all ascii chars must be allowed for password. From NIST 5.1.1.2:
  • fixed by issue Discussion of unicode password requirement V2.1.4 #691

All printing ASCII [RFC 20] characters as well as the space character SHOULD be acceptable in memorized secrets.

Note: from NIST point of view, requirements for "max length 64", "allow all ascii chars", "allow unicode" and "no composition rules" are with keyword SHOULD.

Password content

Current:

• V2.1.7 Verify that passwords submitted during account registration, login, and password change are checked against a set of breached passwords either locally (such as the top 1,000 or 10,000 most common passwords which match the system's password policy) or using an external API. If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password. If the password is breached, the application must require the user to set a new non-breached password.
• V2.1.10 Verify that there are no periodic credential rotation or password history requirements.

Problems:

• V2.1.7 is a monster - contains 3 different requirements
• V2.1.7 is looking only for breaches, must look "password blacklist" in general

NIST 5.1.1.2:

When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:

• Passwords obtained from previous breach corpuses.
• Dictionary words.
• Context-specific words, such as the name of the service, the username, and derivatives thereof.

Recommendations:

• Recommendation no 3: V2.1.7 - split it to 3 different requirements (remove current version of V2.1.7)
• Recommendation no 4: add requirement, that password should not contain dictionary words and "1337 speaking version" of them (example: password > pa55w0rd) (part of passwords blacklist)
  • you may argue, that with min length 12 list of dictionary words are quite limited, in real world I can not see min length for 12 happening any time soon, because sites and businesses want to keep their visitors.
• Recommendation no 5: add requirement, that password should not contain expected and context-specific words, like user data or site data and "1337 speaking version" of them (example: owaspasvs > 0wa5pasvs) (part of passwords blacklist).
• Recommendation no 6: add requirement (first part of current V2.1.7), that password can not be something, which is available in breaches (part of passwords blacklist)
• Recommendation no 7: add requirement (second part of current V2.1.10), that application must not blacklist previously used passwords and must not keep password history
  • if application keeps password history and it leaks, it causes even more damage
  • moved to issue Discussion/Proposal: split 2.1.10 to 2 separate requirements #940
• Recommendation no 8: add requirement (modified first part of V2.1.7) Verify that passwords submitted during account registration, login, and password change are checked against password blacklist.
  • It makes sense to check it against password blacklist, not only against breaches. If blacklist is modified, it affects all users.
• Recommendation no 9: add requirement (replaces last part of V2.1.7), that if on authentication, password is found from blacklist, user is forced to change it.
• Recommendation no 10: add requirement (replaces last part of V2.1.7), that if on authentication, password is found from breach, user is forced to reactivate account.
  • If password is found from / available in breach, it's possible, that some attacker authenticated.
  • I kept it separate from previous one, to be able to set this requirement from Level 2 or Level 3.
• Recommendation no 11: add requirement (middle part of V2.1.7), If using an API a zero knowledge proof or other mechanism should be used to ensure that the plain text password is not sent or used in verifying the breach status of the password.

Note: from NIST point of view, requirements for "no periodic change" and "allow unicode" are with keyword SHOULD.

Userinterface requirements

Current:

• V2.1.8 Verify that a password strength meter is provided to help users set a stronger password.
• V2.1.11 Verify that "paste" functionality, browser password helpers, and external password managers are permitted.
• V2.1.12 Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as native functionality.

Recommendations:

• Recommendation no 12: split V2.1.11 to separate requirements. At least "paste" and rest of it separately.
  • update: does not matter too much, let it be.

Discussion: V2.1.11 "browser password helpers" - does it mean "autocomplete"? Personally I don't think it's best idea, because it's possible to read autofilled credentials from authentication form with XSS on background without any user-interaction at all or with one keypress or click on site needed (depends on browser). If I compare risks or likelyhoods - I guess XSS is widespread enough compared to "with autocomplete users may use stronger password".

In NIST, all mentioned "requirements" are with keyword SHOULD. From "Legend" in OWASP ASVS (example https://github.com/OWASP/ASVS/blob/master/4.0/en/0x11-V2-Authentication.md), those requirements must have "mark" o "Recommended, but not required" instead of ✓ "Required".

[averell23]

Just a few thoughts. First off, wether to split certain requirements is probably a matter of taste, so I'm not weighing in on this.

Recommendation 2: Seems already there. 2.1.4 requires unicode characters to be allowed, and unicode is a superset of all ASCII characters.

Recommendation 3 and onwards: Together, they seem to add a lot of complexity for a moderate benefit. A breach list (The HIBP one is around 9GB...) will already contain all "popular" passwords, including dictionary words of most languages, their "leet" forms as well as human names, their leet forms and more.

The only thing not likely to be in there are context-specific words, but then there is a question on how much complexity you add for this in comparison on to how often they are used.

Also, while I think there'll be some pushback against 12 characters minimum, this has probably the greatest benefit of all recommendations. In the end it will happen if standards mandate it - heck, people even got used to the old NIST rules with arbitrary requirements for special characters (and those were worse, UX-wise, than an 12-char password).

[averell23]

Regardless of the above, I haven't found any rationale for the 12-character password recommendation. Why not the 8-char NIST, or 23? The only thing I found was a "we had to" in a presentation, which didn't actually shed light.

Also, some of the concerns above could be addressed by changing the phrasing from "breached" to "vulnerable passwords" in the standard.

[elarlang]

Regardless of the above, I haven't found any rationale for the 12-character password recommendation. Why not the 8-char NIST, or 23? The only thing I found was a "we had to" in a presentation, which didn't actually shed light.

Related issue/question-answer: #730

[jmanico]

That’s fair, I defer to Andrew van der Stock on this one.

…

-- Jim Manico @manicode

On Apr 12, 2020, at 4:18 PM, Elar Lang ***@***.***> wrote:  Regardless of the above, I haven't found any rationale for the 12-character password recommendation. Why not the 8-char NIST, or 23? The only thing I found was a "we had to" in a presentation, which didn't actually shed light. Related issue/question-answer: #730 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[tghosth]

Just reading back over this. There seems to be a lot going on here. I think we should have one issue per suggested change unless you want to create a large PR to help illustrate each change. What do you think @elarlang?

[elarlang]

My clear idea here is to put entire set of password rules to discussion and get some feedback - we can not solve them separately because they are all related.

[tghosth]

Ok so let's revisit in the runup to 4.1

[stiiin]

I disagree with the idea that recommentation no. 1 is just a matter of style.

I do understand that the two halves of 2.1.10 are not independent. Password history requirements arise when system administrators believe it is important to mitigate CWE-262/CWE-263, and notice or anticipate that users will learn to update their password twice when the password history only consists of a single entry. However, in most cases, these are two separate moves. When system administrators stop requiring periodic changes, they may forget to also repeal password history requirements.

As #840 suggests, verifying 2.1.10 as a whole requires two different strategies for each half. The first half essentially requires a design review, while the second half could be easily falsified through use of the system.

What I've also noticed, is that the cited CWE definition and NIST section only explicitly mention the first half of the requirement:

V2.1.10a: Verify that there are no periodic credential rotation requirements.

The cited NIST section contains a similar requirement ("Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."), and the cited CWE clearly opposes this requirement (more about that in #871).

Because the second half is included, at first glance, the references appear to also lend credence/support to the second half:

V2.1.10b: Verify that there are no password history requirements.

However, this requirement is not present in the cited NIST section. In fact, I can't find anything about password history requirements anywhere in that NIST publication. This requirement is of course again opposed by the cited CWE definition ("... a user is required to update with a new and different password."), but only vaguely. I can't find any CWE that goes into detail on how to ensure that "new and different" bit.

I think splitting the requirement would be a good idea, while only retaining the references for the second half the first half.

[jmanico]

V2.1.10b: Verify that there are no password history requirements. As a side note, I sent a letter to the NIST 800-63 leadership about this and will get back to you. - Jim

On 11/8/20 6:04 AM, stiiin wrote: I disagree with the idea that @elarlang <https://github.com/elarlang>'s recommentation no. 1 is just a matter of style. I do understand that the two halves of 2.1.10 are not independent. Password history requirements arise when system administrators believe it is important to mitigate CWE-262/CWE-263, and notice or anticipate that users will learn to update their password twice when the password history only consists of a single entry. However, in most cases, these are two separate moves. When system administrators stop requiring periodic changes, they may forget to also repeal password history requirements. As #840 <#840> suggests, verifying 2.1.10 as a whole requires two different strategies for each half. The first half essentially requires a design review, while the second half could be easily falsified through use of the system. What I've also noticed, is that the cited CWE definition and NIST section only explicitly mention the first half of the requirement: V2.1.10a: Verify that there are no periodic credential rotation requirements. The cited NIST section <https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver> contains a similar requirement ("Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."), and the cited CWE <https://cwe.mitre.org/data/definitions/263.html> clearly opposes this requirement (more about that in #871 <#871>). Because the second half is included, at first glance, the references appear to also lend credence/support to the second half: V2.1.10b: Verify that there are no password history requirements. However, this requirement is not present in the cited NIST section. In fact, I can't find anything about password history requirements anywhere in that NIST publication. This requirement is of course again opposed by the cited CWE definition ("... a user is required to update with a new and different password."), but only vaguely. I can't find any CWE that goes into detail on how to ensure that "new and different" bit. I think splitting the requirement would be a good idea, while only retaining the references for the second half. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#683 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCP7WZFOVFS7V4I63SDSO26QNANCNFSM4I4OLNWQ>.

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

[jmanico]

Comment from Jim Fenton, the author of NIST 800-63 "There are two different password history issues. Usually password history refers to keeping a user from reusing a password they have used previously. That’s mostly an issue if you’re requiring subscribers to periodically change their passwords, which 800-63B advises against. Accordingly, 800-63B doesn’t contain any requirements to maintain a history of past passwords used by subscribers. However, there is no prohibition on doing so; this would be considered to be an additional risk mitigation measure beyond the requirements of the specification. The other issue you allude to has to do with the contents of blocklists. Breach data may be used to create a blocklist, but you’re correct there isn’t any specific guidance on doing so. I would personally advise against using a very large breach corpus like Have I Been Pwned as the blocklist, because it is so large that users may be frustrated trying to come up with something that isn’t in that huge list. The focus is on trying to avoid the use of very common passwords that might be guessed in online guessing attacks." - Jim Fenton

On 11/8/20 6:04 AM, stiiin wrote: I disagree with the idea that @elarlang <https://github.com/elarlang>'s recommentation no. 1 is just a matter of style. I do understand that the two halves of 2.1.10 are not independent. Password history requirements arise when system administrators believe it is important to mitigate CWE-262/CWE-263, and notice or anticipate that users will learn to update their password twice when the password history only consists of a single entry. However, in most cases, these are two separate moves. When system administrators stop requiring periodic changes, they may forget to also repeal password history requirements. As #840 <#840> suggests, verifying 2.1.10 as a whole requires two different strategies for each half. The first half essentially requires a design review, while the second half could be easily falsified through use of the system. What I've also noticed, is that the cited CWE definition and NIST section only explicitly mention the first half of the requirement: V2.1.10a: Verify that there are no periodic credential rotation requirements. The cited NIST section <https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver> contains a similar requirement ("Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."), and the cited CWE <https://cwe.mitre.org/data/definitions/263.html> clearly opposes this requirement (more about that in #871 <#871>). Because the second half is included, at first glance, the references appear to also lend credence/support to the second half: V2.1.10b: Verify that there are no password history requirements. However, this requirement is not present in the cited NIST section. In fact, I can't find anything about password history requirements anywhere in that NIST publication. This requirement is of course again opposed by the cited CWE definition ("... a user is required to update with a new and different password."), but only vaguely. I can't find any CWE that goes into detail on how to ensure that "new and different" bit. I think splitting the requirement would be a good idea, while only retaining the references for the second half. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#683 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEBYCP7WZFOVFS7V4I63SDSO26QNANCNFSM4I4OLNWQ>.

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

[elarlang]

As there are quite a lot of changes in analyzed requirements, I close thise out.

Summary of this monster:

• Recommendation 1: done, Discussion/Proposal: split 2.1.10 to 2 separate requirements #940
• Recommendation 2: done, Discussion of unicode password requirement V2.1.4 #691
• Recommendation 3: done, [For Improvement] Removal of checking of passwords during login against a set of breached passwords for 2.1.7 #841
• Recommendation 4: not done
• Recommendation 5: not done
• Recommendation 6: done, [For Improvement] Removal of checking of passwords during login against a set of breached passwords for 2.1.7 #841
• Recommendation 7: done, Discussion/Proposal: split 2.1.10 to 2 separate requirements #940
• Recommendation 8: not valid anymore, changed in [For Improvement] Removal of checking of passwords during login against a set of breached passwords for 2.1.7 #841
• Recommendation 9: not valid anymore, changed in [For Improvement] Removal of checking of passwords during login against a set of breached passwords for 2.1.7 #841
• Recommendation 10: not valid anymore, changed in [For Improvement] Removal of checking of passwords during login against a set of breached passwords for 2.1.7 #841
• Recommendation 11: not valid anymore, changed in [For Improvement] Removal of checking of passwords during login against a set of breached passwords for 2.1.7 #841
• Recommendation 12: let it be