Google 身份验证器的 6 位数字为什么能一致？图解 TOTP 与共享密钥

关于本文
本文采用利用生成式 AI 的自动化生成流程创建。我们于 2026 年 11 月 6 日确认了 NIST、Google、Microsoft、RFC 等官方规范，并从用户身边的常见疑问切入进行了解析。

验证状态：📘 已确认官方规范／未在实际账户中进行注册、登录及 WordPress 显示

上方原创图表是用于理解其机制的概念图。它并未复现实际界面或机密信息，仅通过正文的 Mermaid 图表和说明就能理解相同的结论。

“为什么即使在飞机上，身份验证应用里的数字也一直在变？”当智能手机接收不到网络信号时，屏幕上依然会显示 6 位左右的验证码，这让人不禁好奇应用到底在后台做些什么。Google Authenticator 等应用所采用的代表性方法被称为 TOTP（基于时间的一次性密码）。

TOTP 并不是每次都从服务器接收验证码。智能手机端与登录服务侧在注册时持有相同的密钥，并利用根据当前时间计算出的数值各自进行运算。它们会确认这两个计算结果是否一致。这里所使用的是共享的秘密信息这与通行密钥的公钥密码机制不同。

为什么最初的二维码很重要

注册身份验证应用时，服务有时会显示二维码。在常见的 TOTP 中，二维码包含注册信息，例如秘密信息、账户标识名、代码位数和计算方法。并非所有服务都使用完全相同的内容。读取该二维码的身份验证应用会注册该信息，并将其用于下一次登录。

此二维码不只是用于说明的图片。如果将真实的注册二维码展示给他人，该人员可能会存在注册相同秘密信息的风险。就像不应将密码发送给他人一样，TOTP 的共享秘密也必须受到保护。本文不会发布真正的二维码、密钥或实际的 6 位代码。即使在分享公司设置屏幕截图时，也要小心不要拍入注册二维码。

注册后，服务会要求输入应用上显示的验证码，以确认双方是否都能够使用相同的秘密。然而，即便完成了注册，丢失智能手机也并不意味着一定能够恢复。应当将身份验证方法的注册和恢复手段的准备视为两项独立的操作。

图解：在两个地方进行相同的计算

sequenceDiagram
    participant U as 利用者
    participant S as ログインサービス
    participant A as スマホの認証アプリ
    S-->>U: 登録用のQRを表示
    U->>A: QRを読み取って登録
    Note over S,A: 同じ共有秘密を持つ
    A->>A: 秘密と現在時刻からコードを計算
    A-->>U: 数字を画面に表示
    U->>S: 数字を入力
    S->>S: 秘密と時刻から期待値を計算
    S-->>U: 一致と利用条件を確認

在此图中，需要注意的一点是，未描绘出生成代码时智能手机与服务之间的通信。因为只要知道时间和秘密，就可以在各自的位置进行计算。虽然输入时需要与服务器进行通信，但要在屏幕上显示数字本身并不一定需要网络连接。

为什么数字会以固定的间隔改变？

规定了 TOTP 标准的 RFC 6238 展示了一种将时间划分为固定区间并将其用作计算输入的方法。典型的时间跨度为 30 秒。但是，实际服务采用的位数、时间跨度或算法取决于具体设置。不能断言“任何身份验证应用都必定是 6 位数且时间跨度为 30 秒”。

该计算利用了名为 HMAC 的使用密钥的消息验证机制。TOTP 建立在名为 HOTP 的方法基础之上，可以理解为它使用了根据当前时间导出的值来代替 HOTP 使用的计数器。易于输入的短数字可以通过按一定规则转换原始计算结果来获得。由于数字较短，服务器端需要适当限制尝试次数，并且应避免多次连续输入失败。

对于想要了解更多信息的人RFC 6238中的算法要求（Algorithm Requirements）会很有帮助。它解释了共享秘密需要相同的时间区间。如果想进一步了解基础机制，可以阅读RFC 4226，从而确认从使用 HMAC 的 HOTP 到 TOTP 的关联。

如果改变一个条件：智能手机的时间发生偏差

如果智能手机的时钟与正确时间产生重大偏差，应用计算的区间和服务器端的区间可能会不一致。虽然服务侧有时会允许微小的时间差，但允许多少秒并没有统一标准。如果显示代码错误，则不应立即大幅更改智能手机的设置，而应进行安全的排查。

首先，确认所选的服务与账户组合是否正确。其次，查看代码是否刚切换完毕或是否已过有效时间。然后，检查终端操作系统的自动时间设置是否已启用。与其连续多次输入导致被锁定，不如按正确的顺序进行确认，这样可以减少损失。

flowchart TD
    A["コードが受け付けられない"] --> B{"正しいサービス名か"}
    B -->|"いいえ"| C["登録名を確認する"]
    B -->|"はい"| D{"有効時間内か"}
    D -->|"いいえ"| E["次のコードで試す"]
    D -->|"はい"| F["OSの時刻同期を確認"]
    F --> G{"解消しないか"}
    G -->|"はい"| H["サービスの公式復旧手順へ"]
    G -->|"いいえ"| I["通常のログインへ"]

该图仅表示确认顺序，并不意味着可以忽视尝试次数限制或企业的账户保护策略。在需要联系管理人员的环境中，应优先遵循该流程。不建议故意更改终端时钟来对生产业务服务的行为进行实验。

Google 身份验证器可以更换设备吗？

Google 身份验证器具有将代码同步到 Google 账号的功能，但也存在不进行同步即可使用的方法。根据是否使用同步功能，更换设备时的操作会有所不同。考虑到同步目标账号可能无法使用以及设备可能丢失，请提前确认各个服务的恢复方法。

Google 官方帮助说明了可以在离线状态下生成验证码、同步或手动迁移、处理设备丢失以及确认时间是否准确的方法。通过搜索找到的旧步骤中，菜单名称可能与当前应用程序不同。我们将官方资料作为确认当前版本中可以执行哪些操作的依据。

对于能够发行备用代码的服务，应将其与身份验证应用分开妥善保管。恢复代码不是普通的便签，而是可用于验证身份的机密信息。如果怀疑秘密二维码或注册密钥外泄，可能需要使该注册信息失效，并按正规流程重新注册。

6 位验证码应对钓鱼攻击的局限性

验证码会在短时间内更改，但这并不意味着可以消除诱导用户在伪造网站上当场输入验证码的攻击。攻击者可能会在登录过程中索取验证码，并将其转发给真正的服务。TOTP 的“一次性”属性与“应将验证码交给谁”这一技术绑定属性是不同的。

NIST 的SP 800-63B并未将手动输入的 OTP 视为具有抗钓鱼能力的方法。但这并不意味着应该草率地放弃 TOTP。这代表着它在提高密码安全性的同时，根据重要性需要与通行密钥等其他方式进行比较。

工作环境中的使用运维

企业使用 TOTP 时，需要确定由谁来批准应用注册与重新注册、在更换设备时如何验证身份，以及如何使旧注册失效。服务台绝不能轻易要求用户自行保管的机密备份，也不能通过电子邮件共享二维码。日常的便利性与事故发生时的应对措施都需要进行设计。

此外，在监控中，如果连续出现登录失败的情况，切勿武断地认为“只是用户输入错误”，而应核对设备时间、注册的服务、尝试发生的时间以及用户的申报。切勿将调查不需要的实际代码记录在日志中，也不要随意分发个人信息，这些同样非常重要。

需要明确的误解

“因为能显示验证码，所以使用的是服务器的公钥”这种想法是不对的。TOTP 采用的是共享机密的方式。“因为数字是 6 位，所以机密本身也是 6 位”也是不对的。注册时的共享机密是其他信息。“没有网络就无法在智能手机上使用”通常也是错误的。代码的生成本身可以在离线状态下进行。不过，与登录目标的通信、同步以及迁移等操作则需要网络连接。

即使显示相同的 6 位数字，也不意味着可以展示共享机密

即使显示的数字是 6 位，作为基础的共享机密也并不直接等同于 6 位数字本身。它是利用长期保存的秘密和当前时间，转换为易于输入的短数字。在允许无限次尝试短数字的服务中会存在风险，因此服务器端必须妥善管理尝试次数、有效期和重复使用。用户看到的验证码输入框背后，还有许多其他的防御机制。

如果两个身份验证应用拥有相同的时刻、相同的机密和计算条件，它们可能会显示相同的验证码。这两台手机并没有在进行通信。虽然这在正确的迁移过程中是有用的性质，但在他人的注册二维码被复制的情况下也可能会发生相同的情况。正因如此，应当像对待密码一样谨慎对待注册用的二维码。

更换设备前需要确认的顺序

在初始化旧智能手机之前，请确认是否可以在新设备上登录各个服务，以及是否可以通过备用代码或其他方法恢复。在 Google 身份验证器中，虽然有同步和手动迁移的方法，但具体情况因服务而异。不要因为有同步功能就盲目保证所有注册目标的迁移都能成功。在完成新设备的确认之前，保留旧设备的信息会更安全。

当智能手机丢失时，问题在于手头没有验证码的情况下如何证明身份。请查阅所用服务的官方恢复流程，如果是企业账户，则遵循管理员的重新注册手续。有可能出现假冒客服趁您急于恢复之际索要备用代码的情况。在将机密值交给他人之前，请务必确认联系方式是否为官方渠道。

与短信数字的区别

通过短信收到的验证码虽然也是临时数字，但其生成和分发方式与TOTP不同。TOTP是由身份验证应用根据共享密钥和时间计算得出的，因此数字的显示本身并不一定需要移动网络。而短信则是服务方生成内容后通过通信网络发送的代表性方式，需要处于可接收状态。重要的是不要仅凭外表数字就认为它们是相同的技术。

另一方面，这两种方式都存在用户将数字泄露给虚假网站输入框的可能性。不能因为身份验证应用具有不同于短信的优点，就认为它自动具备了防范钓鱼攻击的机制。应当确认您正在访问的服务是否正确，并在重要用途中比较通行密钥等其他方式。

无需在服务台询问验证码

当用户咨询“验证码无法使用”时，应避免通过聊天让对方发送真实的6位数或注册二维码。可以通过服务名称、账户选择、是否更换了设备、操作系统的时钟设置、卡住的界面等非机密信息来进行排查。必要时，在进行规定的身份验证后，再进行重新注册。

RFC 6238规定了验证码的计算方法，但它并不是规定Google Authenticator菜单名称或同步操作的文档。计算原理可参考RFC 6238，而终端迁移与设置则可阅读Google官方帮助文档，这样可以避免混淆标准与产品指南。学习技术有助于在不盲目收集机密的情况下提供支持。

总结

身份验证应用中的数字是利用共享密钥和时间进行计算的结果。注册二维码属于机密信息的原因、即使没有信号也能显示数字的原因、时钟不同步容易导致失败的原因，都可以通过这一套机制来解释。关键不在于记住这6位数，而在于保护共享密钥、确认正确的登录地址、以及确保遇到困难时的恢复手段。

应该阅读哪些官方资料？

• RFC 6238：了解关于TOTP的时间、共享密钥以及30秒间隔的标准处理方式。

• RFC 4226：确认HOTP和HMAC是TOTP计算的基础。

• Google Authenticator官方帮助：了解代码显示、同步、终端迁移以及时间不一致时的应对方法。

• NIST SP 800-63B：确认OTP的有效期、防止重用以及防钓鱼能力的局限性。

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