Enforce password complexity

[runleveldev]

The manager should enforce password complexity via https://github.com/dropbox/zxcvbn

This should apply to all newly registered accounts, password changes, and anytime someone logs in. The third case it to catch anyone that had a previous account with a weak password, or if password requirements are updated, and prompt them to change it immediately. This will only apply to manager logins and not other LDAP-bound logins since the gateway doesn't support complexity rules.

[horner]

I would like to not force a highly complex password if 2FA is being used. If we have 2FA, the addition of complexity in the password is not needed.

[runleveldev]

NIST SP 800-63-3 requires that 2 authentication factors are used (one "memorized secret" or password, and, in our case, an "Out-of-Band Device"). For Memorized Secrets, the following guidelines should be followed¹:

Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. [...] No other complexity requirements for memorized secrets SHOULD be imposed.

However,

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. [...] 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. [...] 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.

Per these guidelines, you're right that we shouldn't use my previous suggesting of zxcvbn by Dropbox, but we should at a minimum implement length requirements and breach detection.

Footnotes

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