TL;DR这是安全性与可用性的关系。我更喜欢并提倡 GitHub 的做法；如果用户已经使用 2FA 会话登录，则在进入“敏感”帐户区域（更改电子邮件地址或 2FA）时需要密码，然后允许禁用 2FA。禁用后，发送通知电子邮件。

这主要是用户体验专家和安全专家之间的斗争。一方面，如果安全人员/gal 可以逃脱惩罚，他们将需要密码、电子邮件确认令牌、2FA 令牌，甚至可能还需要一个 SMS 令牌。但这只会阻止那些在经历了可怕的 UX 之后可能会永远禁用 2FA 的用户。

如果用户已经使用 2FA 登录，则可以合理地假设此浏览器中的会话不是由攻击者发起的。因此，在同一会话中要求 2FA 是多余的。但是，要求输入密码是一种很好的做法，因为该机器可能是共享的或由用户无人看管。这正是 GitHub 的做法：

如果用户未登录：遵循常规 2FA 登录流程并继续下面的操作。

如果用户已经使用 2FA 会话登录：

1. 即将进入危险区禁用2FA的用户：

2. 要求他们使用密码重新进行身份验证：

3. 为他们提供禁用 2FA 的选项，无需其他任何操作：

4. 最后，也是非常重要的，向用户发送一封电子邮件通知，说明 2FA 已禁用。

由于此更改的性质，与更改密码或启用2FA 不同，我认为这里没有必要强制注销所有会话。

这里的答案取决于组织的风险偏好和威胁状况。正如@adi 指出的那样，在这种情况下，可用性和安全性之间存在权衡。

对我来说，允许在不重新输入某种凭据的情况下删除 2FA 会使应用程序处于危险之中，攻击者可以访问活动会话（例如通过会话劫持，或在共享 PC 环境中），因此仅适用于较低风险的应用程序（那么问题可能是，为什么你首先有 2FA ......）

所以选项是，你需要什么重新认证的方式来执行 2FA 的删除。

如果您只允许密码+经过身份验证的会话（github 方法），那么您在某种程度上冒着 PC 恶意软件风格攻击的风险，其中攻击者可能拥有静态密码（通过键盘记录器）和活动会话（通过从浏览器中转储信息） ，但是一旦攻击者拥有对您的客户端系统的特权访问权限，无论如何，您都处于非常糟糕的境地。

另一种选择是要求设置 2FA 时记录的备用令牌。这无疑对用户体验不利（很容易丢失您可能在几年前设置的令牌），并且在用户执行诸如在用于登录的 PC 上明文存储令牌之类的操作时也可能被削弱。

第三种选择是使用另一个渠道来确认操作。这可能只对更高价值的系统有意义（例如网上银行、公司内部特权访问）。在这里，用户通过另一种机制进行验证（例如 SMS 消息、通过电话进行的带外确认）

您不能要求他们使用他们的第二个凭据进行身份验证，因为这会为丢失第二个因素（例如，放错硬令牌）的用户创建一个 catch-22。

删除 2FA 应该类似于忘记密码流程。在这两种情况下，用户都忘记或放错了他的因素之一；更改因子的工作流程，无论是密码还是2FA，都应满足相同的安全级别，但不能要求原始凭据或因子。

通常，这种流程涉及替代因素的数据输入（例如，电子邮件地址和出生日期，伴随着 CAPTCHA），然后是OOB OTP。例如，您可以通过电子邮件向用户发送重置链接或向他们发送短代码。

在任何情况下，对其任何凭据的更改都应始终触发电子邮件或 SMS 通知。