什么是多因素认证？从零解读谷歌和微软的登录

关于本文
本文采用生成式AI辅助的自动化流程创建。我们于2026年11月6日核实了NIST、谷歌、微软、RFC等官方规范，并从用户身边的常见疑问出发进行了讲解。

验证状态：📘 已核实官方规范／尚未进行实际账户的注册、登录及WordPress显示测试

上方原创图表为便于掌握机制的概念图。并未复现实际界面及保密信息，即使仅依靠正文的Mermaid图表和说明也能理解相同的结论。

“密码明明正确，却提示我通过智能手机进行确认”。这是在公司的Microsoft 365、谷歌账户以及银行等服务中常见的画面。您或许会觉得变麻烦了，但这其实是为了区分仅知道密码的第三方与真正的使用者。首先，我们将“为什么要确认两次”这一问题拆解为运行机制与身边的例子来进行说明。

多因素认证（MFA）是将本人所拥有的不同类型的凭证组合起来的理念。代表性的三种类型是“所知道的信息”（密码或PIN码）、“所拥有的物品”（注册过的智能手机或安全密钥）以及“本人的特征”（指纹或面部等）。这些类别的区别非常重要，并不是说仅仅出现两个确认界面就能称之为多因素。

例如，如果只是让密码输入两次，那么就是在两次核对知识。即使增加密保问题，主要也是为了确认本人所掌握的知识。而如果仅凭密码无法批准，必须使用已注册的智能手机，则需要提供不同类型的证据。不过，组合是否合理、本人确认的强度是否足够，取决于所采用的技术。

结合实际界面区分类型

打开自己正在使用的服务的安全设置，仅阅读已注册的认证方法名称也能学到很多。无需删除设置或禁用认证方式。我们想要确认的是“是手动输入6位数验证码”、“手机会收到通知”，还是“选择通行密钥并要求解除设备锁定”这样的区别。

如果界面显示的是输入6位数验证码，那么利用时间生成数字的TOTP机制就是一个候选方案。Google Authenticator就是其中的代表性应用。它并不是每次都从互联网接收验证码，而是根据应用与服务共享的密钥进行计算，因此在无法联网的场景下也能显示。也就是说，“认证应用生成数字”与“使用公钥密码”并不是同一个概念。

Microsoft Authenticator除了验证码外，还具备使用推送通知进行批准、数字匹配以及在受支持环境下的通行密钥等多种功能。即使登录界面上出现相同的应用名称，它所核对的内容也不止一种。将通知中显示的数字与登录界面上的数字进行匹配的方法，和使用公钥验证签名的通行密钥是两种不同的技术。了解了这些区别，就能避免仅凭产品名称来判断安全性的风险。

使用智能手机的面容识别时，自己的脸会被发送到网站吗？在许多通行密钥方案中，面容或PIN码只是用于启用终端认证器的本地验证。服务方会使用公钥来验证由私钥生成的证据。这并不意味着所有的面容识别都是这种机制，但切勿将其与把面容图像发送到网站的方式混为一谈。

图解：将验证的内容分开考虑

sequenceDiagram
    participant U as 利用者
    participant S as ログインサービス
    participant A as 登録済み認証アプリ
    U->>S: パスワードを入力
    S-->>U: 別の証拠を要求
    U->>A: 自分のログインか確認
    A-->>U: コード表示または承認案内
    U->>S: 方式に合った追加確認
    S-->>U: 条件を満たせばサインイン

该图是将典型流程归纳在一起的概念图。在TOTP中，验证码通常由人工输入，而推送通知则使用应用侧的通信，因此内部路径有所不同。它们的共同点是，目的不仅限于密码，还要核实额外的证据。实际的登录界面和可用的方法会因合同或组织设置而异。

改变一个条件：如果泄露的信息增加会怎样

假设某个虚拟用户重复使用密码，并且密码仅被第三方知晓。如果没有附加认证，就会存在仅凭该字符串就被登录的风险。接下来，假设某个服务还需要已注册的认证应用的验证码。第三方仅凭密码将很难继续下一步，这就是引入MFA的意义。

但是，如果用户将当前的验证码甚至输入到了外观极其逼真的钓鱼网站上，又会如何呢？如果攻击者在短时间内将该验证码转发到真实网站，那么即使使用了TOTP也可能被恶意利用。也就是说，单凭多要素认证这一名称，并不能断定它就“一定能防范网络钓鱼”。手动输入的验证码与同网站名称绑定的通行密钥，所能防范的攻击有所不同。

NIST的官方资料将手动输入的OTP与具备防钓鱼能力的方案区分开来。这并不是说OTP毫无意义。针对密码泄露增加一道防线非常重要，但防范向钓鱼网站提供验证码的攻击还需要其他准备。在说到“强大的MFA”时，需要同时考虑我们希望防范的是哪种攻击。

flowchart TD
    A["認証を見直す"] --> B{"パスワードだけか"}
    B -->|"はい"| C["異なる要素を登録する"]
    B -->|"いいえ"| D["方式を区別する"]
    C --> D
    D --> E{"コードの手入力か"}
    E -->|"はい"| F["フィッシングへの限界も知る"]
    E -->|"いいえ"| G["通知かパスキーか確認"]
    F --> H["重要な用途では耐性の高い方法を検討"]
    G --> H
    H --> I["紛失時の復旧経路も用意"]

在此图的最后加入恢复环节是有原因的。如果仅仅因为注册了认证方法就高枕无忧，那么在设备丢失或更换机型时，用户自己可能会无法登录。安全性不仅包括不让外人进入，还包括在合法的本人遇到困难时能够安全地返回。

为了在丢失智能手机时不陷入困境

认证应用中注册的信息，根据服务不同，其迁移和同步的条件也会有所不同。Google Authenticator既有将验证码同步到谷歌账号的方法，也有不同步、仅保留在设备侧的方法。哪种方式更合适，取决于设备的运维、同步目标账号的保护以及丢失时的恢复方法。认为只要同步了就一定能恢复，这种想法是危险的。

同时也要确认服务提供的备用代码或备用认证方法。恢复代码可能只能使用一次，必须由本人安全保管。请勿将真实的备用代码或注册二维码贴在文章、聊天记录或工作票据中。如果是企业账号，则应遵循组织的重新注册规则，切勿跳过本人确认环节来更改方法。

工作中是如何引入的？

在公司里，相比仅凭密码登录，使用附加方法可以更好地加强对非法登录的防范措施。但是，如果一刀切地强制推行，可能会将没有智能手机的用户、正在更换终端的用户以及应急响应人员排除在外。管理员需要划分目标群体，进行小规模验证，并在确认可以正常访问业务应用后再进行推广。

此外，如果智能手机上显示“请批准”而登录并非由本人发起，则应拒绝批准。因为连续收到通知而顺手点击的“通知疲劳”，是即使增加认证也依然存在的风险。微软的数字匹配是一项旨在让用户意识到其与登录界面之间关联的措施，但并不能完全消除伪造网站或社会工程学诱导的影响。

在衡量实施结果时，仅看“注册人数”是不够的。我们需要确认管理员注册的是哪种方式、未覆盖人员的安全替代方案、更换设备时的咨询渠道，以及收到不需要的批准通知时的联系方式。在从日志中调查失败倾向时，也应顾及各位用户的权利和隐私，将目的限定在特定范围内进行处理。

常见问题

“两步验证和多因素身份验证是一样的吗？”即使有两个步骤，如果只是询问了两次相同类型的信息，也不能称为不同的因素。我们应该确认具体的身份验证方法，而不是看服务自身独特的称呼。

“如果使用身份验证应用，就一定采用公钥密码体制吗？”不是的。我们需要将 TOTP 的共享密钥、推送通知的批准以及通行密钥的公钥密码体制区分开来考虑。

“只有人脸识别的话就不是双因素吗？”也有将使用的终端/身份验证器与本地用户确认相结合的设计。我们甚至需要了解服务器会验证什么样的证据。

“既然有了多因素身份验证（MFA），密码就可以随便设置吗？”如果是使用密码的方式，该密码也需要继续受到保护。防止密码重复使用、共享和泄露的基本原则不会改变。

MFA 实施后的运维很困难

在企业中，如果强制所有用户使用相同的身份验证方法，会在意想不到的地方出现问题。例如，无法将个人智能手机带入工作场所的人、持有公司配发终端的人、因出差而网络不稳定的人、以及仅在紧急情况下进入管理后台的负责人，他们可使用的手段各不相同。为了提高安全性而采取的方法不能妨碍本人的业务，因此必须梳理好对象和替代方案。

切勿从一开始就为全体员工进行切换，而是应通过少数人的试用来确认新方法的注册、登录和更换设备，并测试其是否能用于业务应用程序。仅凭注册人数无法衡量实施的成功与否。因为即使通过了登录界面，如果无法访问公司的文件或业务系统，对用户来说工作就没有完成。

不明批准通知切勿点击

如果自己没有开始登录，智能手机却收到了批准请求，请不要批准并予以拒绝。因为通知经常发送而为了“赶紧结束它而点击批准”的行为是很危险的。在数字匹配中，请确认它是否与您正在使用的登录界面上显示的数字相对应。但是，由于在同一终端上使用应用程序等情况会导致屏幕行为不同，因此无法仅凭特定的屏幕截图来解释所有环境。

微软的官方数字匹配资料有助于确认使用了哪些批准方法。批准通知与使用通行密钥进行与服务名称绑定的签名是不同的机制。两者有时看起来都像身份验证应用，但切勿仅凭产品名称来进行判断。

如果不考虑终端丢失的情况，连本人也会被锁在外面

如果注册的终端发生故障或丢失，即使密码正确，有时也无法继续操作。因此，应提前确认恢复路径，例如备用代码、备用注册方法、由组织重新注册等。恢复用的信息也是机密，请勿随意粘贴到聊天或电子邮件中。

如果公司的服务台仅凭电话就可以更改任何人的身份验证方法，那么即使加强了普通登录，恢复的窗口也可能成为薄弱环节。请事先确定身份验证的步骤、何时使旧终端的注册失效、以及由谁来检查记录。这就是为什么需要将强 MFA 和安全的恢复机制结合起来设计的原因。

MFA 之后仍然存在的安全措施

即使 MFA 成功实施后，仍然会存在一些问题，例如表示浏览器登录状态的会话被盗、终端感染恶意软件、或者账户被赋予了过多的权限。仅凭加强身份验证并不能防范所有的非法访问。必须将终端保护、最小访问权限、日志监控以及用户教育结合起来。

具体来说，应考虑为重要的管理员账户采用防钓鱼能力强的方式，并为普通用户准备可用的身份验证方法和安全的恢复机制。还要决定如何报告本人未申请的身份验证通知，以及由谁来调查账户异常。比起启用功能本身，在真正遇到困难时能够安全地进行应对，才是运维上的价值所在。

总结

多因素认证不仅仅是增加登录画面。它将不同类型的证据结合起来，即使密码泄露也能更有效地防止未经授权的登录。然而，认证应用的验证码和通行密钥在技术和局限性上有所不同。选择时需综合考虑要保护的资产、使用者以及丢失时的恢复流程，这才是真正有用的MFA部署。

应该阅读哪些官方文档？

• NIST SP 800-63B：通过标准定义确认认证要素、防钓鱼能力以及恢复机制。

• Google Authenticator 官方帮助：在产品官方文档中确认验证码、更换设备以及同步的处理方式。

• Microsoft Authenticator 官方说明：将验证码、通知和通行密钥区分为不同的方式。

• 微软官方关于数字匹配的说明：了解推送通知中的数字所验证的内容。

返回“安全技术与实际应用”连载目录。