TOTP 时间窗计算器

TOTP（RFC 6238）把共享密钥与「当前时间 ÷ 30 秒」的时间计数器一起做 HMAC，截取 6 位作为口令。服务器与验证器各自独立计算，无需联网同步——这就是 Authenticator 断网也能用的原因。但两方时钟不可能完全一致（手机快 20 秒、服务器慢 10 秒很常见），所以服务器验证时通常接受「当前窗 ±1 窗」三个时间窗的口令——你的口令在一个窗口边界前后最长能存活 30 × (1+2) = 90 秒，最短则正好卡在边界只剩几秒。

这个机制带来三个工程认知：① 时钟同步是 TOTP 可靠性的命门——手机开自动对时（NTP），服务器集群间时钟差要 <1 秒，Docker 容器时区不影响但时钟漂移影响；② 窗口容差是安全与可用性的权衡——±2 窗更宽容但暴力尝试的空间 ×5，金融系统常用 ±0 严格模式；③ 重放防护必须自己加：同一窗口内同一口令第二次提交应拒绝（记 nonce），否则截获的口令在窗口内可复用。本工具计算任意步长/容差/时钟偏移下的口令存活区间与重叠概率。

6 位口令的截取细节决定了兼容性：HMAC-SHA1 输出 20 字节，动态截断取最后一个字节的低 4 位作为偏移量，从该偏移取 4 字节并抹掉最高符号位，再对 10^6 取模——这套「动态截断」让任何实现算出的口令都一致，同时避免负数与大端小端差异。知道这一点就能理解为什么各家 Authenticator 对同一密钥显示相同口令，也能解释 8 位口令版本只是取模改成 10^8。

时钟漂移的来源可以量化：手机靠 NTP 自动对时，漂移通常在 1 秒内；硬件令牌用廉价晶振，精度 20–50ppm，一年自然漂移 10–26 分钟——这就是为什么硬件令牌两三年后会大面积误拒，运维上要做年度重新同步。服务器侧的风险在集群：多台机器各自验证时，彼此时钟差必须压到 1 秒以内，否则用户在 A 机登录成功、B 机失败，排查极其痛苦。

容差窗口的安全账要算清：容差 ±w 让同一时刻有效口令变成 1+2w 个，暴力尝试的成功空间随之放大同样倍数。但放到完整威胁模型里看：6 位口令空间 100 万，在线验证必然配合限速（每分钟几次），即使放大 5 倍，期望破解时间仍以百年计——真正的风险不是容差，而是缺少限速与重放防护。容差的取舍逻辑与 破解时间计算器 的在线场景一脉相承。

TOTP 在动态口令家族中的位置：HOTP（RFC 4226）用计数器代替时间，没有时钟问题但有「计数器失步」问题（用户在验证器上按了 100 次而服务器只认第 3 个）；短信验证码胜在零部署但怕 SIM 交换与拦截；推送确认（点「是我」）体验最好且防钓鱼，代价是必须联网。现行业界共识：普通账户 TOTP 起步，高价值账户上硬件安全密钥（FIDO2），短信只做兜底。

落地清单五条：① 服务器与手机都开 NTP 自动对时；② 验证端记录已用口令（nonce），同窗口拒绝第二次提交；③ 注册时强制抄写恢复码——可用 密码生成器 生成高强度恢复码；④ 提供多设备登记或安全迁移通道，避免换机锁死；⑤ 容差从 ±1 起步，只有硬件令牌场景才放宽到 ±2，并在日志里记录每次验证的偏移量用于漂移预警。