把散落各处的 2FA 密钥收拢到一起，顺便评估迁移码能不能当备份

Q: 能不能把迁移二维码打印出来当备份？

可以，但要清楚它的三个致命属性。优点：(1) 一张图装下几十个账号，离线、不依赖任何软件；(2) 恢复时扫一次就全进去了，比逐条手输快得多；(3) 纸质件不会被远程攻破。致命缺点：(1) 完全明文，没有任何密码保护 —— 谁拿到谁就能算出你所有账号的验证码；(2) 永不过期 —— 密钥是长期凭证，不像验证码几十秒就失效，五年前的码今天照样能用；(3) 没有版本概念 —— 后来新增的账号不在里面，而你很难记得上次打印是什么时候。如果要这么做：(1) 打印件按和护照同级的东西保管，锁在保险箱里，不要拍照、不要存网盘；(2) 在纸上写清打印日期和包含的账号数；(3) 新增账号后重新打印并销毁旧件。更稳妥的替代是服务方给的恢复码——它们是一次性的，泄露的损失小得多。

Q: 各家密码管理器怎么把密钥导出来？

多数支持导出 otpauth:// 链接，具体入口各不相同。通用规律：(1) 在导出/备份功能里选包含 TOTP 字段的格式（常见是 CSV 或 JSON）；(2) 有些提供单条目的「显示密钥 / 显示二维码」，适合只搬几个；(3) 导出文件里 TOTP 那一列通常就是完整的 otpauth://totp/... 链接，直接整列粘出来即可。两个必做的动作：(1) 导出文件是明文的，用完立刻删除，并清空回收站——不要留在下载目录里；(2) 导出前确认这个账号的 TOTP 字段确实有值，很多人以为存了，其实当初只存了密码。顺带一个判断：把 TOTP 和密码放在同一个密码管理器里，等于两个因素共用一把主密钥——方便，但严格说已经不是双因素了。关键账号建议分开放。

Q: 收拢完之后该做什么？

四件事，缺一件就等于没搬完。(1) 逐个核验 —— 新验证器里每个账号的当前验证码，和旧来源算出来的比一遍，全对上再往下走。这一步不能抽查，必须逐个；(2) 实际登录一遍关键服务 —— 核验码只证明算法对，登录才证明这个密钥确实是那个账号的。人最容易犯的错是把账号名贴错，码是对的但对应的是另一个服务；(3) 重新生成恢复码 —— 旧的恢复码可能已经躺在某个不该在的地方，顺手换一批并妥善存放；(4) 清理旧来源 —— 旧手机上的账号、导出的明文文件、临时截图、剪贴板历史，逐一删掉。顺序不能反：先确认新的能用，再删旧的。

Q: 哪些账号不该只靠 TOTP？

能重置其他一切的那几个。具体是：(1) 主邮箱 —— 几乎所有服务的找回密码都发到这里，它一旦失守，别的账号的两步验证也拦不住；(2) 域名注册商和 DNS —— 拿到域名就能接管邮件和证书；(3) 密码管理器本身；(4) 云服务商的主账号 —— 可以看到所有资源和数据。建议：这几个上硬件安全密钥（FIDO2 / 通行密钥），它对钓鱼有结构性的免疫——密钥和域名绑定，假网站拿不到可用的凭证，而 TOTP 的六位数你会亲手输进钓鱼页面。成本：两把硬件密钥（一把随身、一把锁起来）的钱，比丢掉主邮箱的代价低得多。其余的账号用 TOTP 完全够用，不必全部升级。

用了几年两步验证之后，多数人的状态是这样的：一部分密钥在密码管理器里，一部分在旧手机的验证器里，还有几张当初扫码时顺手截的图躺在相册，以及一叠不知道还有没有效的恢复码。

哪个账号在哪儿，自己也说不清。

收拢这件事的麻烦不在技术，在于 Google Authenticator 能导出却不能批量导入——它只提供「转移账号 → 导出」，加账号只能一个一个扫。从别家搬过来的人拿着一堆 otpauth:// 链接，无从下手。

好在它的迁移格式是公开可构造的，Authenticator 批量导入做的就是反向这一步。

第一步：列清单，而不是急着导

把所有开了两步验证的服务列出来，逐个标记密钥在哪。

这一步的主要价值不是整理，是「想起来」——列到一半通常会发现两三个完全忘掉的账号：某个很久不登的云服务、公司内网、一个测试账号。

五种来源，各自怎么取

来源	怎么取	注意
密码管理器	导出功能，选含 TOTP 字段的格式	导出文件是明文，用完立刻删
旧手机的 GA	转移账号 → 导出账号，得到一张迁移码	账号多会拆成几张，要全部截图
当初的原始二维码	截图还在就能直接扫	相册里的截图是个风险，搬完删掉
纸上抄的 Base32	直接用	注意 `0/O`、`1/I` 手抄错认
取不到的	回原服务重新绑定	会作废旧密钥，这是好事

关于密码管理器，有个判断值得说一句：把 TOTP 和密码放在同一个管理器里，等于两个因素共用一把主密钥。方便，但严格说已经不是双因素了。关键账号建议分开放。

第二步：打包成一张码

把收集到的东西每行一条粘进去，三种写法可以混着填：

otpauth://totp/GitHub:me@example.com?secret=JBSWY3DPEHPK3PXP&issuer=GitHub
GitHub:me@example.com:JBSWY3DPEHPK3PXP
JBSWY3DPEHPK3PXP

后两种按默认参数处理（TOTP、6 位、SHA-1、30 秒）。

账号多时会自动拆成几张码——二维码容量有限，装得太密手机对不上焦。这几张属于同一批，要每张都扫，少扫一张就缺账号。这和 GA 自己导出时的做法一致，迁移码内部那层 protobuf 结构见 otpauth-migration:// 里装了什么。

一个格式限制：迁移格式的位数字段只有 6 位和 8 位两个取值，7 位的账号写不进去，只能在验证器里手动添加。

第三步：核验，然后真的登录一次

这两件事是分开的，都不能省：

逐个核验验证码 —— 新验证器里每个账号的当前码，和旧来源算出来的比一遍。必须逐个，不能抽查
实际登录一遍关键服务 —— 核验码只证明算法对，登录才证明这个密钥确实属于那个账号

第 2 条针对的是一个很常见的错误：账号名贴错了。码算得完全正确，但它对应的是另一个服务。这种错误在核验阶段发现不了，只有真的登录才会暴露——而等到某天真需要登录时才发现，就很被动了。

第四步：清理，顺序不能反

先确认新的能用，再删旧的。

旧手机上的验证器账号
导出的明文文件（下载目录、回收站）
相册里的二维码截图
剪贴板历史（很多输入法和剪贴板工具会留存）

顺便重新生成一批恢复码：旧的可能已经躺在某个不该在的地方，趁这次一并换新。

迁移码能当备份吗

可以，但要清楚它的性质。

优点

一张图装下几十个账号，离线，不依赖任何软件
恢复时扫一次就全进去
纸质件不会被远程攻破

致命缺点

完全明文，没有任何密码保护 —— 谁拿到谁就能算出你所有账号的验证码
永不过期 —— 密钥是长期凭证，不像验证码几十秒就失效，五年前的码今天照样能用
没有版本概念 —— 后来新增的账号不在里面，而你很难记得上次是什么时候打印的

真要这么做的三条纪律：

打印件按和护照同级的东西保管，锁起来。不要拍照、不要存网盘
在纸上写清打印日期和包含的账号数
新增账号后重新打印并销毁旧件

更稳妥的替代是服务方给的恢复码——它们是一次性的，泄露的损失小得多。密钥备份的几条路和各自的安全性排序，见 2FA 验证器怎么迁移。

哪些账号不该只靠 TOTP

收拢的过程正好是重新审视的机会。能重置其他一切的那几个账号，值得升级：

主邮箱 —— 几乎所有服务的找回密码都发到这里
域名注册商和 DNS —— 拿到域名就能接管邮件和证书
密码管理器本身
云服务商主账号

这几个建议上硬件安全密钥（FIDO2 / 通行密钥）。它对钓鱼有结构性的免疫——密钥和域名绑定，假网站拿不到可用的凭证；而 TOTP 的六位数，你会亲手输进钓鱼页面。

两把硬件密钥（一把随身、一把锁起来）的成本，比丢掉主邮箱的代价低得多。其余账号用 TOTP 完全够用，不必全部升级。