Modify account-unlock workflow as to not normalize phishing-like behavior
Once an account has been locked due to the maximum amount of failed log-in attempts being carried out, ten theoretically but five effectively atm https://gitlab.com/gitlab-org/gitlab-ce/issues/58316, an account is automatically locked and remains in this state for ten minutes unless the user clicks on an authenticated link sent by us.
|account is locked and the user receives a prompt to unlock their account|
Concerns have been voiced by Sid and others with regard to this workflow (https://gitlab.slack.com/archives/C5W3VS1C4/p1556815216085000), as it normalizes typical phishing workflows to some extent and may therefore put GitLab users at risk.
Once the user clicks on the authenticated link, they are shown a
account successfully unlocked message and brought to GitLab's login page.
|account has been successfully unlocked and user is redirected to GitLab's login page|
Supposing a user isn't attentive to the fact that our e-mails always come from
email@example.com, a malicious third party could 1. send e-mails that mimic those of GitLab depicted above and 2. set a simple web-server with a similar enough domain-name to which users are brought once they click through the malicious e-mail and which logs credentials used for login attempts.
This issue is meant to gather our discussion around the alternatives for this workflow and choose the best one that:
translates to changes we would be comfortable and don't imply a regression wrt to security or UX
doesn't inadvertently encourage or normalize risky user behavior
@gitlab-com/gl-security/appsec @gitlab-com/gl-security/secops @asaba
@clenneville for UX
Login users via the received authenticated token once they click on it without asking for credentials. The assumption here being: "an attacker wouldn't have been able to generate a valid token and in case of e-mail compromise, we aren't responsible."
This option still encourages and expects users to click on links coming from us. Therefore, we most likely should refrain from implementing it. Furthermore, many users read their emails from their mobile devices and it's not clear whether a user would want to be "forced-logged-in" only by trying to unlock their account.
We modify the account-unlock workflow so that:
- we don't include action prompts in the initial notification e-mail
- we only let the users know their account has been locked and that they will have to do an email confirmation during next login
- upon their next login attempt, the user is prompted to unlock their account by either:
- clicking on a link sent by us to them
- entering a one-time-code we send to them
Although this approach potentially still relies on links, after the first post-lockout login attempt, there is one key difference. The e-mail and the link contained therein have been triggered at will by the user, who now, expects some sort of interaction.
Admittedly, account lockouts and password-resets are very nuanced topics https://www.troyhunt.com/everything-you-ever-wanted-to-know/. Should we decide to go with approach 2, any other or leave the process as it currently is, we should carefully evaluate its merits as to avoid re-processing and user confusion.
Approach 2 is the favored approach. We should avoid training users to regularly click on links that we send to them. Generate and send an unlock code via the account unlock email in plaintext. Present the user with an unlock prompt on the login page. Allow them to resend the code if they didn't receive it.
One might argue, and I agree, that this is a "multi-tiered" issue and attention must be payed to what we want to secure and how. The likelihood of a successful account compromise via phishing would decrease, should the following outstanding issues/suggestions be implemented:
Makes a DoS scenario against users such as https://gitlab.com/gitlab-com/gl-security/operations/issues/222 unlikely
Makes logging into GitLab by leveraging stolen credentials, obtained for example through phishing, as in https://gitlab.com/gitlab-com/gl-security/operations/issues/225 unlikely as we turn geographical location into a sort of "second factor"
Notifies users when their credentials have potentially been compromised in a timely manner and gives them a course of action so that issues such as https://gitlab.com/gitlab-com/gl-security/operations/issues/110 don't materialize.
It might be worth discussing whether tackling this particular issue with an isolated change is the best approach or if a WorkGroup should be started that looks at the security workflows within GitLab itself from a holistic perspective is a better approach.