TOTP 动态口令生成器
按 RFC 6238 用 Base32 密钥算出当前动态码，本地计算不上传，可用于核对身份认证系统的时间同步。
TOTP 动态口令生成
密钥只在您的浏览器里参与计算，不会发送到任何服务器。当前剩余有效时间 — 秒。
——
这个工具做什么
TOTP（Time-based One-Time Password，基于时间的一次性口令）是 RFC 6238 定义的标准算法，手机上的身份验证器、硬件令牌、企业统一身份平台大多按这个标准生成六位动态码。本工具按 RFC 6238 计算当前时间窗口内的动态码，可以用于核对服务端与客户端的时间是否同步。
算法本身分三步：把 Base32 密钥解码成字节，用 HMAC-SHA1 对「当前时间戳除以步长」的计数器签名，再从签名结果里按动态截断规则取出一段数字。三步都是公开可复现的，所以只要密钥和时钟一致，两边算出来的码必然相同。
什么时候会用到
- 接了双因素认证后，用户反映动态码总是提示错误，需要判断是密钥不对还是服务器时间偏了
- 自建身份系统上线前，用已知密钥比对标准实现的结果，验证自己的算法写对了
- 排查令牌漂移，确认服务端 NTP 同步是否正常
时间偏差是常见故障
TOTP 默认 30 秒一个窗口，服务端通常允许前后各一个窗口的容差。如果服务器时间偏差超过 60 秒，用户就会持续验证失败，而客户端看起来一切正常。这类问题排查时先看两侧系统时间，再看密钥是否一致，比反复让用户重新绑定效率高得多。
常见参数对照
| 参数 | 常见取值 | 说明 |
|---|---|---|
| 算法 | HMAC-SHA1 | RFC 6238 默认值，绝大多数验证器只支持这一种 |
| 时间步长 | 30 秒 | Google Authenticator、微软验证器、阿里云 MFA 均为 30 秒 |
| 位数 | 6 位 | 少数系统用 8 位，位数不一致会直接验证失败 |
| 容差窗口 | 前后各 1 个 | 即实际有效区间约 90 秒，超过就要校时 |
| 密钥长度 | 160 位（32 个 Base32 字符） | 短于 128 位不建议在生产使用 |
常见问题
TOTP 动态码为什么每隔 30 秒就变？▼
因为计数器取的是当前时间戳除以步长的整数商，时间每跨过一个 30 秒窗口，计数器加一，签名输入随之改变，输出自然不同。服务端校验时通常允许前后各一个窗口的容差，所以实际有效期约 90 秒。
密钥填进去安全吗？▼
本工具的计算全部在浏览器内完成，密钥不经过网络，也不写入任何存储。关闭页面后输入即清空。不过从安全习惯上讲，生产环境的密钥不建议贴进任何网页工具，测试用的密钥可以。
动态码一直提示错误怎么排查？▼
按顺序查三件事：一是服务端和手机的系统时间是否一致，偏差超过 60 秒必然失败；二是密钥是否完整，Base32 密钥少了字符仍能解码出结果，但算出来的码完全不同；三是位数和时间步长配置是否与服务端一致。
支持 SHA256 和 SHA512 吗？▼
RFC 6238 允许使用 SHA256 或 SHA512，但绝大多数手机验证器和云厂商 MFA 只实现 SHA1。如果服务端用的是 SHA256，需要专门的验证器，本工具按最常见的 SHA1 计算。
企业做双因素认证要注意什么？▼
重点是密钥的保管和恢复流程。密钥泄露等于第二因素失效，建议服务端加密存储；同时要准备备用验证方式，避免员工换手机后无法登录。等保二级以上要求对重要用户采用两种以上鉴别技术组合。