Prevent users from choosing weak passwords
Problem to solve
As well-articulated in https://gitlab.com/gitlab-org/gitlab-ce/issues/36568, we should warn users who are using potentially unsafe passwords. Password reuse is common, but potentially unsafe. We should encourage users to use strong, unique passwords when accessing GitLab instances, especially when using GitLab.com.
Proposal
- Check on new user registration with a username/password
- Check on user password update
MVC 1
Form validation when creating a password which checks against known weak passwords.
Not in this proposal
- When a user logs into GitLab with a password, we should check that password against a list.
- Using third-party "pwned" APIs like https://haveibeenpwned.com/API/v2
- Checking existing users outside of a password-changing event (i.e. displaying warning banners at log in)
- Administrator-configurable weak-password list
- Allowing admins to enable/disable the check. See: !86310 (comment 951941665)
- Password complexity. See: #18691 (comment 934751134) / Feature/password complexity on backend (!82798 - merged)
Detail
As a mandatory, non-configurable option, check passwords against a static list of known weak passwords and prohibit users from choosing those passwords. Enforce at registration or when a password is changed. (Do not check or enforce during sign-in).
Also validate the password against components of the user's attributes, such as their name, email, and username.
Notably, this is a requirement of NIST SP 800-63B:
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.
Password complexity is discouraged by that same guidance. Minimum password length and prevention of known, weak passwords is the industry recommended approach.
Availability & Testing
Add tests to ensure passwords containing the following are not accepted:
- Dictionary words from an existing list
- Previously breached password
- User's name, email, phone number and other PI details.