How should disabling 2FA be handled by a service?

Question

Due to personal reasons I recently had to disable and re-enable 2FA on quite a few of services. Now during this action I noticed quite a few different practices when it comes to "what should a user do before being allowed to turn 2FA off".

So the question follows:
What is the most reasonable way to handle deactiviation of 2FA for personal / end-user accounts?

The options I've seen in the wild additionally to "being logged-in" include

• No re-authentication
• Re-authentication (without) using the password
• Re-authentication (without) using one or two 2FA tokens
• (No) E-Mail notification of the account owner
• (No) Forced log-out of the user on all devices

Read all these points in each variation and combination, so "No-PW+1-Token+No-Email+Forced-Log-Out" is included just like "no-to-everything" as is "PW+No-Token+Email+No-Log-Out".

Answer 1

TL;DR It's a Security vs. Usability thing. I prefer, and advocate for, the way GitHub does it; If the user is already logged in with a 2FA'd session, then require the password when entering the "sensitive" account area (changing email address or 2FA), and then allow disabling 2FA. Once disabled, send a notification email.

---

This is largely a fight between the UX expert and the security expert. On one hand, if the security guy/gal can get away with it, they'll require the password, email confirmation token, 2FA token, and maybe even an SMS token on top of that. But that will just deter users who will probably keep 2FA disabled forever after going through that horror of a UX.

If the user is already logged in using 2FA, it's reasonable to assume that this session in this browser is not initiated by an attacker. Thus, requiring 2FA while still in the same session is excessive. However, requiring the password is a good practice since the machine might be shared or left unattended by the user. This exactly how GitHub does it:

If the user is not logged in: Follow regular 2FA login flow and continue below.

If the user is already logged in with a 2FA'd session:

1. User about to enter the danger zone to disable 2FA:

2. Require them to re-authenticate with the password:

3. Give them the option to disable 2FA with nothing else required:

4. Finally, and very importantly, send the user an email notification that 2FA is disabled.

Due to the nature of this change, unlike changing the password or enabling 2FA, I don't think it's necessary here to force-logout all the sessions.

Answer 2

The answer here depends on the risk appetite and threat profile of the organization. As @adi points out there's a trade off between usuability and security in this case.

For me, allowing the removal of 2FA without re-entering some kind of credential leaves applications at risk, where an attacker has access to an active session (e.g. via session hijacking, or in a shared PC environment), so is only really suitable for lower risk applications (and the question then might be, why do you have 2FA there in the first place...)

So the option is, what do you require in the way of re-authentication to execute the removal of 2FA.

If you allow just password+authenticated session (the github approach), then you're somewhat risking PC malware style attacks where an attacker is likely to have static password (via a keylogger) and an active session (via dumping information from the browser), but then once the attacker has privileged access to your client system, you're in a pretty bad place regardless.

Another option woud be to require a fallback token which was recorded when 2FA was set-up. This is doubtlessly bad for user experience (it's very easy to lose a token that you setup potentially years ago), and also potentially is weakened where the user's do things like store the tokens in the clear on the PC used to login.

A third option is to use another channel to confirm the action. This is likely to only make sense for higher value systems (e.g. online banking, internal company privileged access). Here the user is validated through another mechanism (e.g. SMS message, out of band confirmation via a phone call)

Answer 3

You can't ask them to authenticate with their second credential because that creates a catch-22 for users who have lost their second factor (e.g. misplaced a hard token).

Removal of 2FA should be similar to the forgotten password flow. In both cases, the user has forgotten or misplaced one of his factors; the workflow to change the factor, whether it be password or 2FA, should meet the same level of security, but can't require the original credential or factor.

Typically this sort of flow involves data entry of alternative factors (e.g. email address and date of birth, accompanied by CAPTCHA) followed by a OOB OTP. You could email the user a reset link or text them a short code, for example.

In any case, changes to any of their credentials should always trigger an email or SMS notification to that effect.