Update GitLab.com minimum password length
Proposal
Modify the minimum password length from 8
(current) to 12
(proposed) using the GitLab UI: https://docs.gitlab.com/ee/security/password_length_limits.html#modify-minimum-password-length-using-gitlab-ui
Here's our current signup page:
Also update https://docs.gitlab.com/ee/user/gitlab_com/#password-requirements (which says GitLab.com has a minimum of 8).
Rationale
We currently permit 8 character passwords without complexity. 12 feels like a balance of not too low, not too high. We can iterate if needed, or at least have a transparent discussion on the best outcome.
Threat Model
There are two threats - online login attempts, and offline cracking attempts should some kind of disclosure scenario occur (e.g. db breach).
- .com uses Captcha, Arkose Labs, and rate limiting to deter credential stuffing, which protects users with short passwords
- Users can enable MFA which mitigates the impact of a compromised password (regardless of length)
However there are other flows that accept a password (e.g. git over HTTP), and we shouldn't assume that our rate limiting mitigations will give 100% coverage 100% of the time - we should aim for defense in depth.
Having the .com database breached has a whole host of concerns, and we already use good hashing and salting, but again increasing the minimum length to 12 would only make brute forcing passwords offline slower (which is good).
Our Standards
System Password Requirements... For systems where a password can be configured the minimum password length needs to be set to 12 characters.
GitLab team-members Password Requirements... At GitLab, we enforce a strong password requirement, which consists of minimum length of 12 characters.
GitLab the product (e.g. for self-managed users) encodes a minimum minimum password length of 8.
Industry Standards & Commentary
Many industry bodies recommend a minimum of 8 (NIST, ISO27k). That doesn't necessarily mean GitLab.com should allow the minimum, though.
Memorized secrets SHALL be at least 8 characters in length... No other complexity requirements for memorized secrets SHOULD be imposed. ... Password length has been found to be a primary factor in characterizing password strength. The minimum password length that should be required depends to a large extent on the threat model being addressed.
https://pages.nist.gov/800-63-3/sp800-63b.html
NZ Govt manual specifies:
- a minimum password length of 16 characters with no complexity requirement; or
- a minimum password length of ten characters (with complexity)
https://www.nzism.gcsb.govt.nz/ism-document/
Australian Govt says 14 with complexity (Control ISM-0421).
A Rapid7 article on offline cracking of passwords:
When we analyze sets of cracked passwords, we notice that the most common password length is very often the minimum required length. Not only that, but the minimum length occurs in more than half of the cracked passwords. ... If the company’s policy is set to the minimum required length of eight characters, cracking more than 60% of the entire hashfile is very common. Once that minimum length reaches even 10 characters, my success level drops in half to around 30%. ... my recommendation would still be to require longer passwords and disallow the common passwords
What do others do?
For comparison. We should do what we feel is best for our users.
- GitHub requires 15+ chars, or 8 with complexity. (Notably GitHub will require MFA from 2023)
- Microsoft (live.com) requires 8 chars with complexity.
- Google requires 8 chars with complexity
- Cloudflare require 8 chars with complexity
- Okta require 8 chars with complexity
- Shopify require 5 characters
- Windows recommends administrators set a minimum of 14 or 8
- Devise (the gem) defaults to 6
Speculation
- Increasing to 12 might encourage users to use a password manager
- There's no reason not to set it to something like 16, but I imagine that might have an even greater impact on sign up success rates. With this small step change we could monitor the impacts.
Potential Impacts
- Sign up success rates may be impacted as users can no longer choose short passwords
- Self-managed will not be impacted, as the configuration would only affect .com.
Other related work
- We could enforce complexity, but that is not recommended by NIST: https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#password-complexity-requirements
- We might soon be preventing known, weak passwords: Prevent users from choosing weak passwords (gitlab-org&8139) / Blocks weak passwords on sign up or password ch... (gitlab-org/gitlab!86310 - merged)
- An OKR related to this was opened in FY20 and never actioned: https://gitlab.com/gitlab-com/gl-security/security-department-meta/-/issues/535
Context
I opened this issue here because "Reliability Engineering is responsible for all of GitLab's user-facing services, with their primary responsibility being GitLab.com." (src).
Other
Details
- Point of contact for this request: @nmalcolm
- If a call is needed, what is the proposed date and time of the call: Date and Time
- Additional call details (format, type of call): additional details
SRE Support Needed
- Help identifying the DRI for this configuration so that we can enable Fast Decisions
- Changing the minimum password length.