TOTP 生成器 — 2FA 验证码生成与 otpauth 二维码制作

把 Base32 密钥转换为带倒计时的实时 2FA 验证码，为身份验证器应用生成 otpauth:// 二维码，或解析现有 URI。

密钥（Base32）

可以包含空格和小写字母。160 位密钥。

算法

位数

周期

当前验证码

— — —

上一个 — · 下一个 —

验证码取决于设备时钟。如果验证码被拒绝，请检查时钟是否设为自动；大多数服务器也接受上一个和下一个验证码。

otpauth:// URI 和二维码

发行方

帐户名

otpauth://totp/Example%20Inc:jane%40example.com?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example%20Inc&algorithm=SHA1&digits=6&period=30

用 Google Authenticator、Microsoft Authenticator、1Password、Authy 或任何 TOTP 应用扫描。许多应用会忽略 SHA-256/512 和 8 位数字；除非你能控制两端，否则请保留默认设置。

读取 otpauth:// URI

粘贴 URI（例如来自二维码扫描器）

密钥和验证码只保存在你的浏览器中，不会发送或存储。请像对待密码一样对待 TOTP 密钥：任何拿到它的人都能生成你的验证码。浏览全部免费工具.

发现问题，或者觉得哪里可以更好？每条消息我们都会阅读，并尽快修复。

这款 TOTP 生成器生成的基于时间的一次性验证码，与 Google 身份验证器、Microsoft Authenticator、1Password 等身份验证器应用完全相同。输入 Base32 密钥，就会显示当前的 6 位或 8 位验证码及倒计时，同时显示上一个和下一个验证码。它专为在应用中添加双重身份验证的开发者打造：生成密钥，制作用户要扫描的 otpauth:// URI 和二维码，并检查你的服务器是否接受应当接受的验证码。

验证码在你的浏览器中通过 WebCrypto 的 HMAC 函数计算，遵循 RFC 6238（TOTP）和 RFC 4226（HOTP），实现已通过两份 RFC 中官方测试向量的测试。不会向任何地方发送数据。即便如此，TOTP 密钥和密码一样敏感：任何持有它的人都能生成有效的验证码。请将本工具用于测试账号和集成开发，不要用它代替你真实账号的身份验证器应用。

使用方法

粘贴 Base32 密钥，或点击“新随机密钥”。包含空格或小写字母也没关系。
除非你的服务器使用其他设置，否则算法、位数和周期保持 SHA-1、6 位和 30 秒即可。
查看当前验证码；圆环显示它还有几秒有效。用按钮复制。
填写发行方和账号名称以生成 otpauth:// URI，然后用身份验证器应用扫描二维码，确认两边显示相同的验证码。
要检查现有配置，把它的 otpauth:// URI 粘贴到解析器中，然后点击“加载”。

常见问题

TOTP 验证码是如何工作的？

你的服务器和身份验证器应用共享一个密钥。每隔 30 秒，双方都用该密钥对“自 1970 年 1 月 1 日以来经过的 30 秒步数”计算 HMAC-SHA1，再把结果缩减为 6 位数字。由于双方使用相同的密钥和相同的时钟，无需通信就能得到相同的验证码。这就是 RFC 6238；其底层基于计数器的算法是 HOTP，即 RFC 4226。

为什么我的 TOTP 验证码无效？

最常见的原因是时钟不准。相差超过约 30 秒，设备就会处于不同的时间步；请把设备和服务器都设为自动同步时间。其他原因包括：密钥输错了（Base32 只使用 A–Z 和 2–7，所以永远不会出现 O、I、0、1 和 8），或者服务器要求不同的设置，比如 8 位、SHA-256 或 60 秒周期。

TOTP 中使用 SHA-1 不安全吗？

不是。已知的 SHA-1 弱点是碰撞攻击，即能构造出两个哈希值相同的输入。TOTP 是在带密钥的 HMAC 中使用 SHA-1，这种结构不依赖抗碰撞性，依然安全。SHA-1 至今仍是默认值，因为几乎所有身份验证器应用都支持它。

什么是 otpauth:// URI？

它是 2FA 设置二维码中包含的文本，采用最初由 Google 身份验证器定义的 Key Uri Format：otpauth://totp/Issuer:account?secret=BASE32SECRET&issuer=Issuer，可附加 algorithm、digits 和 period 参数。扫描二维码只是把这个字符串传给应用。任何看到二维码或 URI 的人都拿到了密钥，所以请把设置页面视为敏感信息。

TOTP 密钥应该多长？

RFC 4226 要求至少 128 位，推荐 160 位，也就是 32 个 Base32 字符。“新随机密钥”按钮会用 crypto.getRandomValues 生成 160 位密钥。许多老服务签发的是 80 位（16 个字符）密钥；它们能用，本工具也会对此发出提醒，但新系统应至少使用 160 位。

所有身份验证器应用都支持 8 位和 SHA-256 吗？

不是。otpauth 格式允许 SHA256、SHA512、8 位以及其他周期，但有些应用会忽略这些参数，始终生成 SHA-1、6 位、30 秒的验证码，导致对不上。如果服务器由你控制，默认值是稳妥的选择。在上线非默认设置之前，先用你的用户可能使用的应用扫描本页的二维码，对比验证码是否一致。

在你自己的应用中添加 TOTP

• 在服务器上为每个用户生成至少 160 位的随机密钥，并加密存储而不是哈希存储：服务器需要原始密钥才能计算验证码。

• 把 otpauth:// URI 显示为二维码，同时以文本形式提供 Base32 密钥，方便无法扫码的用户。

• 启用 2FA 之前，要求用户输入一个有效的验证码，以免扫码失败导致用户被锁在账号之外。

• 验证时接受当前验证码，通常再接受前后各一个时间步（即这里显示的上一个和下一个验证码）来容忍时钟偏差，并拒绝在该时间窗口内已经使用过的验证码，防止重放攻击。

• 限制尝试频率。6 位验证码只有一百万种可能，不限次数的猜测就能攻破它。

• 在用户注册 2FA 时发放一次性恢复码，并像密码一样对其进行哈希存储。

TOTP 与短信验证码、推送和通行密钥的比较

TOTP 比短信验证码安全得多——短信验证码可能通过 SIM 卡劫持攻击和 SS7 漏洞被截获——而且 TOTP 离线可用，不需要手机号。它的弱点是网络钓鱼：一个逼真的虚假登录页面可以索要验证码，并在 30 秒的时间窗口内转发到真实网站。

推送确认虽然方便，却容易招来“MFA 疲劳”攻击：攻击者不断发送确认请求，直到用户点了批准。通行密钥（Passkey）和硬件安全密钥（FIDO2/WebAuthn）是常见方法中唯一在设计上就能抵御网络钓鱼的，因为浏览器会把凭据绑定到真实网站的域名上。合理的做法是优先提供通行密钥，同时保留 TOTP 作为支持广泛的备用方案。