Password requirements don't follow NIST standards

[gdevenyi]

The password setting requirements violate best practices as recommended by NIST: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

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

[gdevenyi]

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

[driusan]

Hi @gdevenyi,

I think it's important to take the NIST guidelines as a whole, and not selectively apply them. They don't simply say "don't have any requirements other than an 8 character limit." Selectively applying the parts of the best practices which contradict and relax previously published best practices is without simultaneously implementing the other parts which mitigate the risks is likely worse than using an outdated password requirement scheme.

For instance, this part of the document you linked to is important:

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.
    Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
    Context-specific words, such as the name of the service, the username, and derivatives thereof.

If the chosen secret is found in the list, the CSP or verifier SHALL advise the subscriber that they need to select a different secret, SHALL provide the reason for rejection, and SHALL require the subscriber to choose a different value.

As is this:

Verifiers SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

That said, as a user I agree that the password requirements implemented by LORIS are dated and need to be modernized, but in order to remain secure I think it's import that it be implemented alongside the other updated best practices, and not simply by removing the password strength requirements currently in place as your ticket seems to be requesting.

[driusan]

I went through the requirements and tried to enumerate them in an easier checklist.

The following MUST be done in order to be compliant with the best practices:

• [x] Passwords must be at least 8 characters long
• [x] Randomly generated tokens must be at least 6 characters long
• [ ] Must compare passwords against a blacklist of known passwords when changing (examples of blacklists given in is passwords from previous breach corpuses, dictionary words, repetitive or sequential characters, context-specific words such as the name of the service, username or derivatives thereof.)
• [ ] If password appears in a blacklist, force a different password
• [ ] Provide the reason for rejection if a password is rejected.
• [x] Truncation of the password should not be performed
• [?] Unicode codepoints (not bytes) should be counted as a character
• [x] MUST NOT provide a password hint
• [ ] Implement rate-limiting mechanism for failed login attempts
• [x] Use "approved encryption" and an authenticated protected channel when requesting passwords (ie. use https. This depends on web server configuraton, not LORIS..)
• [x] Store passwords in a form that's resistant to offline attacks
• [x] Salt passwords using a suitable one-way key

The following SHOULD be done, but aren't obligatory according to the standard:

• [ ] No complexity requirements other than the length
• [x] Should permit at least 64 character long passwords
• [x] All printing ASCII characters or unicode characters should be accepted (todo: verify)
• [ ] Unicode should be normalized using either NFKC or NFKD normalization defined in the unicode standard before hashing
• [ ] Provide guideance such as a password-strength meter when changing password
• [x] Permit user to paste passwords
• [ ] Provide an option to display the password rather than asterisks when prompting for it
• [?] Various password hash requirements. Need to verify whether PHP's password_hash function satisfies them (it likely does..)

[gdevenyi]

Sure, I'm totally okay with implementing the whole thing, but I highlighted specifically the content requirements because they are known to cause weaker passwords.

I use a password manager, so my passwords are long, random and can easily satisfy requirements. Other users might have a much harder time.

[gdevenyi]

Troy hunt offers an API for checking known bad passwords: https://haveibeenpwned.com/Passwords

[johnsaigle]

The pull requests just referenced address these issues mentioned above:

• [x] Must compare passwords against a blacklist of known passwords when changing (examples of blacklists given in is passwords from previous breach corpuses, dictionary words, repetitive or sequential characters, context-specific words such as the name of the service, username or derivatives thereof.)
• [x] If password appears in a blacklist, force a different password
• [x] Provide the reason for rejection if a password is rejected.
• [x] Implement rate-limiting mechanism for failed login attempts

The following SHOULD be done, but aren't obligatory according to the standard:

• [x] No complexity requirements other than the length

[driusan]

The full updated list:

• [x] Passwords must be at least 8 characters long
• [x] Randomly generated tokens must be at least 6 characters long
• [ ] Must compare passwords against a blacklist of known passwords when changing (examples of blacklists given in is passwords from previous breach corpuses, dictionary words, repetitive or sequential characters, context-specific words such as the name of the service, username or derivatives thereof.)
• [ ] If password appears in a blacklist, force a different password
• [x] Provide the reason for rejection if a password is rejected.
• [x] Truncation of the password should not be performed
• [?] Unicode codepoints (not bytes) should be counted as a character
• [x] MUST NOT provide a password hint
• [x] Implement rate-limiting mechanism for failed login attempts
• [x] Use "approved encryption" and an authenticated protected channel when requesting passwords (ie. use https. This depends on web server configuraton, not LORIS..)
• [x] Store passwords in a form that's resistant to offline attacks
• [x] Salt passwords using a suitable one-way key

The following SHOULD be done, but aren't obligatory according to the standard:

• [ ] No complexity requirements other than the length
• [x] Should permit at least 64 character long passwords
• [x] All printing ASCII characters or unicode characters should be accepted (todo: verify)
• [ ] Unicode should be normalized using either NFKC or NFKD normalization defined in the unicode standard before hashing
• [ ] Provide guideance such as a password-strength meter when changing password
• [x] Permit user to paste passwords
• [ ] Provide an option to display the password rather than asterisks when prompting for it
• [?] Various password hash requirements. Need to verify whether PHP's password_hash function satisfies them (it likely does..)

[johnsaigle]

I just unchecked the ones relating to blacklisting. #3962 contained that functionality but has since been closed and not merged. #4411 now contains the blacklisting functionality.

[johnsaigle]

4411 was just merged for upcoming LORIS v. 22

Essentially all we need now is a visual indicator of password strength on the front-end.

Here's the list, updated again:

• [x] Passwords must be at least 8 characters long
• [x] Randomly generated tokens must be at least 6 characters long
• [x] Must compare passwords against a blacklist of known passwords when changing (examples of blacklists given in is passwords from previous breach corpuses, dictionary words, repetitive or sequential characters, context-specific words such as the name of the service, username or derivatives thereof.)
• [x] If password appears in a blacklist, force a different password
• [x] Provide the reason for rejection if a password is rejected.
• [x] Truncation of the password should not be performed
• [?] Unicode codepoints (not bytes) should be counted as a character
• [x] MUST NOT provide a password hint
• [x] Implement rate-limiting mechanism for failed login attempts
• [x] Use "approved encryption" and an authenticated protected channel when requesting passwords (ie. use https. This depends on web server configuraton, not LORIS..)
• [x] Store passwords in a form that's resistant to offline attacks
• [x] Salt passwords using a suitable one-way key

The following SHOULD be done, but aren't obligatory according to the standard:

• [x] No complexity requirements other than the length
• [x] Should permit at least 64 character long passwords
• [x] All printing ASCII characters or unicode characters should be accepted (todo: verify)
• [ ] Unicode should be normalized using either NFKC or NFKD normalization defined in the unicode standard before hashing
• [ ] Provide guideance such as a password-strength meter when changing password
• [x] Permit user to paste passwords
• [ ] Provide an option to display the password rather than asterisks when prompting for it
• [?] Various password hash requirements. Need to verify whether PHP's password_hash function satisfies them (it likely does..)

[gdevenyi]

Essentially all we need now is a visual indicator of password strength on the front-end.

https://github.com/dropbox/zxcvbn

[johnsaigle]

We're using Zxcvbn on the back-end as of the PR I linked, but not yet in the front-end.

[johnsaigle]

Closing this because we have separate tickets for the remaining features:

5761 front-end strength estimator.

5293 improve unicode support.