Provide an option for users to recover 2FA without human intervention
Problem Statement
Users are often locked out of their accounts when they lose their 2FA device. If a user loses their recovery codes or don't have a backup recovery method, their only remaining option is to contact Support (for GitLab.com) or their instance admin (for self-managed).
This is problematic for users who experience a lot of friction in the recovery process and for GitLab.com because it introduces a risk vector: people. The additional friction can drastically degrade the user experience for our wider community and the involvement of people from GitLab can open up social engineering or other risk vectors that could affect account security.
Reach
10.0 = Impacts the vast majority (~80% or greater) of our users, prospects, or customers.
Impact and Confidence
3.0 = Massive impact 100% = High confidence
This would have a significant impact in two ways:
- Users would be able to get access to their account without contacting Support
- Support would no longer need to answer a large number of tickets from users locked out of their account, which would also reduce cost; this would also apply to GitLab self-managed admins who can save time
Current workflow and available options
When a user wants to set up 2FA, they can go their account page and enable 2FA. Currently, there are two options:
- 2FA app
- U2F (e.g. Yubikey)
Once set up, they receive their one time use download codes which they should save to use later.
If a user loses the device, the possible ways to get access to the account:
- Use the other 2FA option (e.g. Yubikey if they lost their phone with 2FA app) if it's been set up.
- Use a download code not previously used.
- Generate new codes using SSH.
Objectives
We would like to remove the human factor in the process.
The explicit point of something like 2FA and U2F is to lock out access to those who do not have them. Their purpose is diminished if we have policies that allow them to be circumvented.
At this time, the support team believes we are not ready for deprecation of account recovery as there are not sufficient methods to help users self recover account access.
from https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/1715 (see also, for a lot more discussion and rationale)
Adding recovery methods
Based on discussions, the best options are:
- Email code to verified email (must be a separate email from password reset, which is currently primary email only) #211755 (comment 342311912) -- This option would allow free users to have a recovery path.
- Trusted contact as per #211755 (comment 311486271) -- This option mirrors the process that is currently followed for users in large groups.
Options discussed but not prioritized at this time:
- Using existing session (number of cases this would apply to?)
- Unique information for the user to verify. e.g. latest commit info in given private repo path
- Trusted linked account (e.g. GitHub uses Facebook)
- Security questions
- PAT: gitlab-foss#63281 (closed)
- enforce SSH key with 2FA: gitlab-com/support/support-team-meta#2207 (closed) (low ease of use)
- no new feature, but make the process more intuitive, visible, and efficient
- SMS code: #30026 (too many security concerns, but better than nothing); Note: this research from Google, which suggests that in spite of the security risks of using SMS codes, an SMS code sent to a recovery phone number helped block 76% of targeted attacks, so one may consider offering it as a fallback
More background
For other suggestions and possible follow up issues, please refer to these comments in particular