有了双因素认证（2FA），即使密码泄露，单凭密码也没人能登录进来。下面梳理它与常被混淆的两步验证的区别，以及各方式的对比（不写攻击手法）。
「两个因素」与「两个步骤」的区别
两个词看着相似，但只要抓住目标就很简单。认证因素分为三个类别：
**双因素认证（2FA）**混合两个不同的类别（例如密码 = 知识 + 身份验证器应用 = 持有）。要点是：即使一个被攻破，另一个类别仍然有效，攻击者也进不来。
相比之下，两步验证（2SV）只意味着「确认两次」，两个步骤可以是同一类别（密码 + 安全问题是两个步骤但不是两个因素）。所以若真想要强度，关键在于混合不同的类别。
方式的强弱：取决于假网站能否窃取你输入的内容
即便开启了 2FA，强度也会因方式而大不相同。决定性因素是：你会不会一不小心把「证明」交给假网站。
强 ── 通行密钥 / 物理密钥（FIDO2）
签名绑定到域名——从结构上无法对假网站出示（抗钓鱼）
中 ── 身份验证器应用（TOTP）
比 SMS 强，但验证码要由人来读——所以可能被交给假网站
弱 ── SMS / 邮件验证码
验证码可能被钓鱼；SMS 还面临手机号劫持
弱：SMS / 邮件验证码
- 由人读取并输入验证码——所以可能被直接交给假网站
- SIM 交换针对手机号上的 SMS 或语音接收。邮件验证码依赖邮箱及其恢复机制的保护；两种手动输入的验证码都可能被钓鱼。
- 但仍明显强于仅有密码（远胜于没有）
强：通行密钥 / 物理密钥（FIDO2）
- 签名绑定到网站的域名——不可能对假网站出示
- 单独用通行密钥或安全密钥实现 MFA 时，服务必须要求并验证 PIN、生物识别等用户验证。安全密钥也可与密码组合使用；仅触碰以确认人在场不等于第二种因素。
- 身份验证器应用（TOTP）居于两者之间——比 SMS 强，但仍可能对假网站出示
2FA、两步验证、MFA、OTP 与通行密钥的区别
相似的术语之所以多，是因为表示思路的词和表示方式的词混在了一起。
| 术语 | 含义 | 例子 |
|---|---|---|
| 双因素认证（2FA） | 组合两种不同类别证明的思路 | 密码 + 身份验证器应用验证码 |
| 多因素认证（MFA） | 组合两种或以上不同类别证明的思路（包括 2FA） | 签名绑定域名；要求用户验证时使用 PIN 或生物识别 |
| 两步验证（2SV） | 确认两次（两次可以是同一类别） | 密码 + 安全问题 |
| 一次性密码（OTP） | 常被用作第二重证明的一次性验证码 | 来自身份验证器应用、SMS 或邮件的验证码 |
| 通行密钥 | 用设备上的私钥签名的登录方式 | 用指纹或面容解锁来登录 |
2FA 和 MFA 描述的是需要满足什么；OTP 和通行密钥描述的是如何满足。验证码见什么是一次性密码（OTP），签名见什么是通行密钥。即使服务的画面上写着「两步验证」，背后往往是密码加身份验证器应用这样的 2FA，所以要按实际的方式来判断。
2FA 能防住多少
微软研究人员在 2023 年对该公司云服务用户进行的一项研究发现，开启 MFA 的账户被入侵的风险总体降低了 99.22%，即使在使用了泄露凭据的情况下也降低了 98.56%。因密码重用或泄露而来的账户被盗，无论用哪种方式，大多只要开启 2FA 就能挡下。
但 2FA 也有挡不住的情况。
- 在假网站上输入：在假网站上输入的 SMS 和身份验证器应用验证码会被中继到真网站。通行密钥和硬件密钥能防止这一点
- 薄弱的恢复手段：如果只凭短信或注册邮箱就能恢复账户，那就会成为入口
- 没有 2FA 的账户：如果攻击者从没有 2FA 的工作邮箱或第三方服务账户进入，你的其他防御就派不上用场
公开事故：区分原因评估与建议措施
运营集团在2019年8月1日公告中认为，使用非法取得的 ID 和密码列表进行攻击的可能性较高。这是公司当时的评估，不代表所有攻击路径都已确定。 同一公告表示，当时未发现外部 ID 关联、密码提醒或人工聊天重置等功能直接导致未授权访问的案例。 截至2019年7月31日17时，认定808人、38,615,473日元损失，包含未授权充值和未授权使用。这是8月1日公告中的时点数据，不是其宣称的最终总数。 7pay 盗刷事件（2019）.
此后，越来越多的服务把 2FA 设为强制，而不是交给用户自行决定。GitHub 从 2023 年 3 月起，逐步要求贡献代码的用户开启 2FA（设置方法见设置 GitHub 双因素认证）。本站对 2026 年 8 月在日本公布的主要事件进行分类时发现，从合法凭据——外包方的 Microsoft 365、工作邮箱、GitHub 凭据——入手的案例，多于利用漏洞的案例（2026 年日本数据泄露的入侵途径）。
如何检查自己的账户
决定顺序
从邮箱和密码管理器开始，因为两者都被用来重置或管理你的其他账户。然后是域名、云和 GitHub，再然后是银行、证券和支付。
检查每个账户的 2FA 方式
在安全设置中，查看 2FA 是否开启、使用的是哪种方式。如果是 SMS 或邮件验证码，添加身份验证器应用或通行密钥并设为首选。各方式的比较见如何正确选择 MFA。
准备恢复码和第二种方式
把恢复码保存在手机以外的地方，例如密码管理器中。同时注册第二种方式，例如备用通行密钥或硬件密钥。
复查恢复用的邮箱和手机号
确认注册的恢复邮箱和手机号仍然归你所有，并且恢复邮箱账户本身开启了 2FA。要确认密码是否已经泄露，请参阅如何检查密码是否已泄露。
如果你管理他人的账户，就把 2FA 设为强制
对于公司邮箱、GitHub 组织和云管理控制台，不要把 2FA 留作可选；在组织设置中设为必须。要求管理员账户使用通行密钥或硬件密钥。
本站的观点：先开启，再转向『交不出去』的方式
2FA 最常见的失败，是在「哪个最强」上想太多，结果一个都没开。优先级很清楚：先在每个账户上开启某种 2FA，然后把最重要的账户（邮箱、域名、支付）迁移到无法对钓鱼网站出示的方式（通行密钥）。
本站不把「靠小心识破假网站」算作一种防御策略。与其依赖人的警觉，不如倾向那些在结构上就无法把证明交给假网站的方式。
出处（一手资料）
- NIST SP 800-63B-4，“Digital Identity Guidelines: Authentication and Authenticator Management”（2025 年 7 月） — pages.nist.gov（认证因素、抗钓鱼、电话网络方式为受限）
- Meyer 等，“How effective is multifactor authentication at deterring cyberattacks?”（Microsoft，2023 年） — arxiv.org（MFA 使入侵风险降低 99.22%，使用泄露凭据时降低 98.56%）
- CISA，“Implementing Phishing-Resistant MFA”（2022 年 10 月） — cisa.gov（PDF）（MFA 方式从强到弱的排序、针对 SMS 的 SIM 交换）
- GitHub Docs，“About mandatory two-factor authentication” — docs.github.com（自 2023 年 3 月起逐步要求）
- 运营集团关于服务终止、调查与应对的公告 (2019-08-01) — 7andi.com
接下来阅读
- GitHub 设置：如何设置 GitHub 双因素认证
- 术语：什么是一次性密码（OTP）（身份验证器应用验证码的原理：TOTP/HOTP/SMS）· 什么是通行密钥（无法交给假网站的最强方式）
- 术语：什么是钓鱼（理解瞄准 2FA 的中间人 AiTM 攻击）
- 入门：如何正确选择 MFA（在实务中选定方式）
- 案例：7pay 盗刷事件（2019）