Loris: Password requirements don't follow NIST standards

Created on 24 Nov 2017 · 12Comments · Source: aces/Loris

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

Feature Security

Source

gdevenyi

All 12 comments

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.

gdevenyi on 24 Nov 2017

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 on 24 Nov 2017

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..)

driusan on 27 Nov 2017

👍1

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 on 28 Nov 2017

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

gdevenyi on 28 Nov 2017

👍1

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

johnsaigle on 19 Sep 2018

🎉1

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..)

driusan on 11 Apr 2019

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 on 11 Apr 2019

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..)