TOTP（一次性密码）生成器
通过 Base32 格式的 TOTP 密钥，在浏览器本地生成与 Google Authenticator 等应用相同的 6 位一次性密码（RFC 6238）。密钥绝不会被发送到服务器。
本工具绝不会将密钥发送至任何服务器。Base32 解码与 HMAC 计算均在您的浏览器内（Web Crypto API）完成，因此可以放心输入身份验证信息。
关于 TOTP 算法
TOTP（基于时间的一次性密码）是 RFC 6238 中定义的、基于时间生成一次性密码的算法。它将共享密钥与当前时间转换为按固定间隔递增的计数器，再使用与 HOTP（RFC 4226）相同的动态截断算法推导出数字验证码。
| HMAC 算法 | 可选择 SHA-1（默认）、SHA-256 或 SHA-512 |
|---|---|
| 验证码位数 | 6 位（与 Google Authenticator 等主流双重验证应用相同的标准位数） |
| 更新周期 | 每 30 秒切换为新的验证码 |
使用提示
- 密钥就是首次注册双重验证（2FA）时，二维码下方显示的“设置密钥”字符串。如果您已在手机验证器应用中注册过，只需在此工具中输入相同的密钥即可核对验证码是否一致。
- 部分服务采用的哈希算法并非 SHA-1（而是 SHA-256 或 SHA-512）。如果生成的验证码与实际应用不一致，请尝试切换算法再试。
- 验证码每 30 秒自动更新一次，进度条可以直观显示剩余时间。请注意，如果在即将切换前复制验证码，可能在送达验证方之前就已失效。
- 关闭浏览器标签页后，密钥会被彻底丢弃，不会保存在任何地方。如果需要作为备份保留，请另行将密钥本身保存在密码管理器等安全的地方。
常见问题
是的。Base32 解码与 HMAC 计算全部在浏览器内通过 Web Crypto API 执行，绝不会发送至服务器。您可以通过监控网络通信来确认输入的密钥并未被发送出去。
这可能是哈希算法不一致（多数服务使用 SHA-1，但部分服务使用 SHA-256 或 SHA-512），或设备时间存在偏差所致。请先尝试切换算法，如果仍然不一致，请检查设备的时间设置（自动时间同步）。
通常认为 TOTP 更安全。短信验证码存在因电话号码被劫持（SIM 卡交换诈骗）而被第三方截获的风险，而 TOTP 完全在设备本地完成运算，不会受到此类攻击的影响。
多数服务在首次设置双重验证时会发放“恢复代码”。如果连密钥本身也遗失了，则需要通过服务方的账户找回流程（身份验证）重新设置双重验证。
闲话 ― 双重验证为何最终定格为“6 位数”
制定 TOTP 规范（RFC 6238）的 OATH（开放身份验证倡议组织）直接沿用了 HOTP（RFC 4226）的动态截断算法，并将验证码的位数交由各实现自行决定。之所以 6 位成为事实上的行业标准，主要是因为 Google Authenticator 在 2010 年的初始实现中采用了这一位数，此后众多服务和库都纷纷效仿。
6 位数字也恰好是一个绝妙的平衡点。一百万种组合（10 的 6 次方）再加上短短 30 秒的有效期，使得暴力破解在现实中几乎不可能实现；而位数再多则会让用户难以记忆和手动输入。多数短信验证码同样采用 6 位并非巧合，而是整个“短时效、一次性数字验证码”这一品类共同收敛出的经验法则。
TOTP 的前身 HOTP（RFC 4226，2005 年）采用“计数器”方式，每使用一次验证码就必须将计数器递增一次。然而由于用户经常忘记操作，或者设备与服务器的计数器发生偏差，运维问题频发。因此 2011 年制定的 TOTP 改用任何人都能参照的统一基准——“当前时间”，大幅简化了运维流程。