TOTP 两步验证怎么用：原理、迁移与安全边界
很多登录页在密码之后还有一步：打开手机、找到条目、抄六位数字，等验证码刷新。这个六位数字通常就是 TOTP（基于时间的一次性密码）。它比短信验证码更可靠，但也常被误解成「绝对安全」。
这篇文章讲三件事：TOTP 到底算的是什么、把它放进密码管理器值不值得，以及迁移时最容易踩的坑。
TOTP 到底算的是什么
TOTP 由 RFC 6238 定义。服务端在你绑定两步验证时生成一个共享密钥，并把它交给你（通常通过二维码或一串文本）。之后每次登录：
- 客户端和服务端都拿这个共享密钥；
- 加上当前时间窗口（默认 30 秒）作为计数器；
- 做一次 HMAC 运算，截取并压缩成 6 位数字；
- 服务端在允许的时间漂移内比对结果。
所以验证码不是随机数，而是密钥 + 时间的确定性结果。它不需要联网，也不依赖短信网络；只要两边时钟大致一致，就能算出一致的码。
TOTP、短信验证码和 Passkey 的区别
- 短信验证码：依赖运营商网络，存在 SIM 换卡、短信劫持和号码回收风险，安全性弱于 TOTP。
- TOTP：不依赖运营商，离线可算，明显优于短信；但它仍然是「可被钓鱼的验证码」——假登录页可以实时索要并转发你的码。
- Passkey / 硬件安全密钥：绑定站点来源，能抵抗大多数钓鱼，是更强的方向；但并非所有站点都已支持。
因此，TOTP 是今天非常实用的第二因素，但不是终点。高价值账户如果支持 Passkey 或硬件密钥，应优先使用。
把 TOTP 放进密码管理器：方便与风险
把 TOTP 和密码放在同一条目里，最大的好处是登录链路不中断：填充密码后，同一处就能拿到当前验证码，不用切 App。对开发者、测试和每天登录大量后台的人来说，这个体验提升很实在。
但要把风险说清楚：
- 如果密码库在解锁状态下被攻破，攻击者可能同时拿到密码和 TOTP 密钥，两个因素就合并成了一个；
- 因此，对银行、支付、主邮箱、云平台根账号等高价值账户，更稳妥的做法是把 TOTP 放在独立验证器或硬件密钥里；
- 对开发 / 测试环境、普通社区账号，把 TOTP 与密码放在一起是合理的便利取舍；
- 无论放在哪里，TOTP 密钥都必须加密存储，不能以明文落盘。
账号密码管理助手把 TOTP 密钥作为独立字段，与用户名、密码、网址、备注一起逐字段加密；验证码在本地按 RFC 6238 生成，登录到第二步时可直接填入。它适合「方便地管理多套日常账号」，但不建议把它当作银行或支付类凭据的唯一保险箱。
迁移 TOTP 的步骤
从手机验证器迁到另一个工具，通常有三种方式：
- 扫码迁移：新工具扫描旧工具或服务端提供的二维码；
- 手动输入密钥：输入 Base32 密钥、账号名、 issuer 与算法参数；
- 导出/导入：部分验证器支持加密导出，注意导出文件本身就是高敏感数据。
迁移时建议按这个顺序：
- 先选一个低风险账号试通，确认新工具生成的码能登录；
- 检查设备时间是否自动同步，时间漂移会导致验证码始终不对；
- 迁移完成后保留旧验证器一段时间，确认新工具稳定再移除；
- 保存服务端提供的一次性恢复码，放在离线安全位置；
- 如果怀疑密钥泄露，立即在服务端重置两步验证，而不是只删掉旧 App。
不要把 TOTP 二维码、密钥截图或恢复码发到聊天工具里。它们和密码一样，是可直接生成验证码的凭据。
浏览器扩展里的 TOTP 如何工作
以账号密码管理助手为例：
- 密钥随条目一起加密存储，只有会话解锁后才能读取；
- 验证码由本地 Web Crypto / RFC 6238 逻辑生成，不发起网络请求；
- 在两步登录页，内容脚本识别验证码输入框，侧边栏或页内胶囊提供当前活码；
- 复制验证码沿用剪贴板定时清除策略，降低截屏或误粘贴的风险。
需要提醒的是：浏览器扩展运行在你的浏览器里，不能防御已被入侵的操作系统、恶意扩展或正在共享的屏幕。开启屏幕共享或远程协助时，先确认验证码页面不在共享范围内。
检查表
- 高价值账户优先使用 Passkey / 硬件密钥，TOTP 作为兼容方案；
- TOTP 密钥加密存储，未解锁时不可读；
- 设备时间自动同步，验证码能稳定通过；
- 迁移前准备恢复码，迁移后保留旧验证器一段时间；
- 不在聊天、截图或共享屏幕中暴露二维码、密钥或验证码；
- 怀疑泄露时在服务端重置，而不是只删除本地条目。
TOTP 的价值在于「多一个独立因素」，而不是「多一道绝对防线」。理解它的计算方式与信任边界，才能把便利留在工作流里，把风险留在可控范围内。
想了解本地加密与密钥管理的实现细节，可以读Web Crypto 加密实践；如果你的日常登录需要内置 TOTP 与一键填充，可以试试账号密码管理助手。