search

OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.69k stars 653 forks source link

Discussion: rules for password format and content #683

Closed elarlang closed 3 years ago

elarlang commented 4 years ago

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:

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 commented 4 years ago

Well, I dig to it more deeply.

Password change functionality

Current:

Recommendations:

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

Current:

Recommendations:

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:

Problems:

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:

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

Userinterface requirements

Current:

Recommendations:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Ok so let's revisit in the runup to 4.1

stiiin commented 3 years ago

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 commented 3 years ago

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.

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 https://github.com/OWASP/ASVS/issues/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 https://github.com/OWASP/ASVS/issues/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 https://github.com/OWASP/ASVS/issues/683#issuecomment-723604645, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEBYCP7WZFOVFS7V4I63SDSO26QNANCNFSM4I4OLNWQ.

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

jmanico commented 3 years ago

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 https://github.com/OWASP/ASVS/issues/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 https://github.com/OWASP/ASVS/issues/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 https://github.com/OWASP/ASVS/issues/683#issuecomment-723604645, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEBYCP7WZFOVFS7V4I63SDSO26QNANCNFSM4I4OLNWQ.

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

elarlang commented 3 years ago

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

Summary of this monster: