这些场景下会用到批量管理
- 云平台与主机面板
- 代码托管与 CI 账号
- 支付与财务后台
- 域名与证书管理
- 企业办公与邮箱
- 外包与临时协作
批量管理要解决的核心问题
2FA 本身不复杂，复杂的是「多」。单个账号开 2FA 只需要扫一次码，但当成百个账号放在一起，密钥的格式、重复、归属和生命周期都会变成管理问题。下面三条是实际工作中最常卡住的地方。
密钥格式不统一，导入就失败
不同平台导出的密钥有带空格、带短横线、大小写混用、带 otpauth:// 前缀等多种写法。批量导入前需要统一做去空格、转大写、校验 Base32 字符集，否则会出现「导入成功但验证码一直错」的情况。工具侧的处理是先规范化再逐条试算一次验证码，通过的才入库。
账号归属不清，离职就断链
密钥绑在个人手机上时，人员离职意味着账号失去第二因素。批量管理要求每条密钥都记录归属人、所属分组、创建时间和最后验证时间，交接时按分组整体转移，而不是靠口头交代。
备份不加密，等于把钥匙放桌上
导出的备份文件包含可直接生成验证码的密钥，明文存放风险极高。常规做法是用口令加密后存储，口令与备份分开保管，并保留最近 3 个版本以便回滚。
核心功能：导入与校验
三种来源批量导入
支持 CSV（列名可映射）、otpauth:// 链接列表、以及从主流验证器导出的 JSON 备份。导入时先预览前 20 条解析结果，确认字段对应关系后再执行全量写入，避免整批数据写错。
逐条试算校验
每条密钥入库前按 RFC 6238 试算一次当前时间窗口的 6 位验证码，算法参数（SHA1/SHA256、6 位/8 位、30 秒/60 秒）可从 otpauth 链接中读取，缺省按 SHA1 + 6 位 + 30 秒处理。
重复密钥检测
按「密钥 + 算法参数」生成指纹，导入时自动标记重复项。常见于同一个账号被多人分别添加过，去重后只保留一条并合并归属记录，减少后续维护量。
失败明细可导出
校验不通过的条目会单独列出原因（字符集不合法、长度不足 16 位、时间参数异常等），可导出为 CSV 交由原平台核对后重新导入，不用整批重来。
分组、权限与二维码
按项目或部门分组
分组支持两级结构，例如「运维 / 生产环境」「财务 / 支付后台」。每个分组可设置默认算法参数，新增账号时自动套用，减少逐条配置。
按人授权查看范围
成员只看到被授权分组的账号列表，验证码按需生成、默认 30 秒刷新。管理员可随时收回某个分组的访问权，收回后该成员立即无法生成对应验证码。
二维码批量生成
可为单个账号生成标准 otpauth:// 二维码用于绑定新设备，也支持按分组导出二维码清单（通常建议每页 12 个、A4 打印），导出文件默认带水印和生成时间。
操作留痕
导入、导出、授权变更、验证码生成四类操作都记录时间与操作人，日志保留通常不少于 90 天，便于事后核对「谁在什么时候动过哪条密钥」。
从零开始的一次完整批量管理流程
下面 6 步是按实际项目顺序排列的，通常一个 100 条左右密钥的团队，从整理到完成交接大约需要 2 到 3 个工作日，其中大部分时间花在核对账号归属上，而不是工具操作本身。
第 1 步：盘点账号清单
先列出所有已开启或需要开启 2FA 的平台与账号，标注归属人和当前第二因素绑在谁的设备上。建议用表格记录「平台 / 账号 / 归属人 / 是否已开 2FA / 密钥来源」五列，这一步通常占整体工作量的一半。
第 2 步：统一导出密钥
从现有验证器中导出备份，或在各平台重新生成密钥。导出后先不要删除原设备上的绑定，等新系统校验通过再解绑，避免中途丢失第二因素。
第 3 步：规范化并导入
把导出的文件整理成 CSV 或 otpauth 链接列表，导入工具后先看预览，确认字段映射无误再全量写入。导入完成后查看失败明细，逐条修正。
第 4 步：建立分组与授权
按项目或部门建分组，把账号归入对应分组，再给成员分配查看权限。原则是最小授权：只给当前工作需要的分组，不按「反正都是同事」全量开放。
第 5 步：导出加密备份
完成整理后立即导出一次加密备份，记录版本号与导出时间，口令单独保管。建议此后每月或每次批量变更后更新一次备份，并保留最近 3 个版本。
第 6 步：验证与解绑旧设备
随机抽取 10% 的账号，用新系统生成的验证码实际登录一次，确认可用后再解绑旧设备上的密钥。全部通过后把盘点表归档，作为下一次交接的基线。
常见密钥格式对照与处理方式
批量导入失败，八成是格式问题。下表列出实际工作中最常遇到的几种写法和对应处理方式，导入前可以对照检查一遍。
| 格式写法 | 常见来源 | 处理方式 |
|---|---|---|
| 带空格或短横线，如 abcd efgh ijkl mnop | 平台页面手工复制 | 去掉空格与短横线后转大写，再校验 Base32 字符集 |
| 完整 otpauth:// 链接 | 二维码解码结果 | 直接解析参数，读取 secret、algorithm、digits、period 四项 |
| 纯 Base32 字符串，长度 16 或 32 位 | 验证器导出备份 | 按缺省参数处理（SHA1 / 6 位 / 30 秒），入库前试算一次 |
| 含小写字母与数字 0/1 | 手工录入或 OCR 识别 | 转大写并检查是否混入字母 O 与数字 0 的误录，逐条人工核对 |
| 同一账号多条记录 | 多人分别添加 | 按密钥指纹去重，保留一条并合并归属人记录 |
需要说明的是，算法参数与平台不一致时，验证码会「看起来正常但一直提示错误」，这类问题只能靠试算校验发现，所以导入环节的逐条校验不能省。
迁移、备份与恢复
换设备不丢密钥
换手机或重装验证器前，先从系统导出加密备份，新设备恢复后逐组核对数量与指纹，确认一致再清理旧设备，避免出现「两边都没有」的空窗期。
人员交接有据可依
交接时按分组整体转移归属人，系统记录转移时间与操作人。接收方首次登录需完成一次验证码试算，确认能正常生成后才算交接完成。
备份版本可回滚
保留最近 3 个加密备份版本，每次批量变更后更新。恢复时先恢复到测试分组验证，再覆盖正式分组，降低误操作影响面。
异常账号单独处理
对长期未验证、归属人已离职、平台已停用三类账号单独标记，定期清理。通常建议每季度做一次，避免清单越滚越大。
安全边界：工具能做什么、不能做什么
密钥加密存储
入库的密钥以加密形式存储，展示时默认脱敏，只有生成验证码时才在内存中解密，减少密钥被整批导出的风险。
不替代平台侧策略
批量管理解决的是「密钥怎么管」，不能替代平台自身的登录风控、异地提醒和权限模型。平台侧的强制 2FA 策略仍需在各自后台单独配置。
最小授权与定期复核
成员权限按分组授予，管理员每季度复核一次授权清单，收回不再需要的访问权。复核记录随操作日志一并保留。
恢复码单独保管
各平台提供的一次性恢复码不要和密钥备份放在一起，建议打印后存于不同物理位置，避免单点丢失导致两个因素同时失效。
价格方案
按密钥条数和管理员人数区分，以下为通常的档位划分方式，具体以实际开通时确认的条数为准。
一个团队通常怎么推进上线
以下时间线按 100 条左右密钥、5 到 10 人团队的常见节奏整理，实际进度取决于账号盘点是否顺利。
- 第 1 周
盘点与导出
完成账号清单，统一导出密钥，确定分组结构与授权名单。这一周通常最花时间，建议由最熟悉账号分布的人牵头。
- 第 2 周
导入与校验
规范化格式后批量导入，处理失败明细，完成第一轮试算校验。通常 500 条以内 3 分钟内可完成一次导入。
- 第 3 周
分组与授权
建立分组、分配成员权限、生成二维码供新设备绑定，并做 10% 抽样登录验证。
- 第 4 周
交接与解绑
按分组转移归属人，解绑旧设备上的密钥，导出第一次正式加密备份并归档版本号。
- 每季度
例行复核
复核授权清单、清理异常账号、更新备份。通常每次复核 30 分钟内可完成，前提是日常变更都有记录。
「以前密钥全在三个人各自的手机里，谁休假谁就成了瓶颈，离职交接更是靠翻聊天记录找。整理成清单之后，最大的变化不是省了多少时间，而是终于能说清楚每个账号归谁、换人时按分组转过去就行。抽样验证这一步我们一开始嫌麻烦，后来发现它是唯一能提前发现算法参数配错的办法。」
一位运维负责人的实际感受 · 某中型互联网公司运维团队，管理约 180 个需要 2FA 的平台账号
常见问题
批量导入后验证码一直提示错误，是什么原因？
最常见的原因是算法参数与平台不一致，例如平台用 SHA256 或 8 位验证码，而导入时按缺省的 SHA1 + 6 位处理；其次是密钥里混入了空格、短横线或字母 O 与数字 0 的误录。建议先看该条记录在导入时是否通过试算校验，未通过的按失败明细逐条修正，通过的再核对设备时间是否偏差超过 30 秒。
把密钥集中管理，会不会反而更不安全？
风险点确实从「设备丢失」转移到了「集中存储」。应对方式有三条：密钥加密存储且展示脱敏、按分组做最小授权、操作日志保留不少于 90 天。此外建议恢复码与密钥备份分开保管，不要放在同一台设备或同一个网盘里，避免单点丢失导致两个因素同时失效。
支持从哪些验证器导出并导入？
通用做法是走标准格式：CSV、otpauth:// 链接列表、以及 JSON 备份。只要导出内容里包含 secret 字段和可选的算法参数，就能解析导入。如果某个平台只提供二维码，可以先用二维码解码得到 otpauth 链接再批量整理，通常几十条在几分钟内可以处理完。
免费版和企业版的主要差别在哪？
差别集中在三处：密钥条数（30 条对 2000 条）、成员与分组授权（免费版单管理员无分组）、以及日志保留时长（免费版不提供操作日志）。如果只是个人整理自己的账号，免费版够用；一旦涉及多人交接和权限收回，就需要团队版及以上。
人员离职时怎么保证账号不断链？
关键在两点：每条密钥都记录归属人和所属分组，交接时按分组整体转移而不是逐条口头交代；接收方完成一次验证码试算后才算交接完成。建议把这两步写进离职流程清单，并在季度复核时检查是否有归属人为空或已离职的账号。
备份文件丢了还能恢复吗？
如果备份和恢复码都丢失，只能走各平台的账号找回流程，周期通常以天计，部分平台需要提交身份材料人工审核。这也是为什么建议保留最近 3 个加密备份版本、口令单独保管，并把恢复码打印后存放在不同物理位置。工具本身不保留可代你找回的明文密钥。
先从一个分组开始试
联系我们
如果你正在处理几十上百个账号的 2FA 整理，或者对导入格式、分组划分有具体问题，可以通过下面的方式联系。描述时建议附上：账号大致数量、当前密钥存在哪里（手机验证器 / 表格 / 截图）、以及是否涉及多人交接，这样回复会更有针对性。
我们通常在工作日 24 小时内回复，涉及导入失败排查的问题，附上失败明细的字段名（不要附完整密钥）会更快定位。
- 邮件咨询 [email protected]，适合描述较长的场景说明和格式问题，可附脱敏后的 CSV 表头截图。
- 导入问题排查 提供失败条目的报错类型（字符集不合法 / 长度不足 / 参数异常）与来源平台名称，通常 1 个工作日内给出处理建议。
- 团队方案沟通 说明团队人数、密钥条数量级和是否需要按部门隔离，我们会按实际规模给出档位建议，而不是直接推最高档。