Off Grid AI 本地 Vault 存 TOTP 验证码教程

把动态验证码留在手机里，几乎成了默认习惯。但如果你经常在电脑前工作，每次登录都要摸手机、切应用、抄六位数字，这个流程其实相当割裂。Off Grid AI Desktop（OGAD）提供了一条纯本地的替代路径：把支持的身份验证器 setup key 存进桌面 Vault 的登录条目，再由配对的浏览器扩展显示当前动态码和倒计时，整个登录过程不需要离开电脑。

本文基于官方发布的 Pro Vault 工作流，拆解 secret 字段的正确用法、常见报错排查，以及这套方案到底在多大程度上算得上“离线”。

这个字段到底支持什么类型的验证码

登录条目里的 One-time code secret 字段接受两类输入：受支持的身份验证器 setup key，或者标准的 otpauth:// 链接。Vault 会用这个 secret 在本地计算随时间变化的动态码。

这里最容易被搞混的一点是：你现在看到的那串六位动态码，不是你需要保存的 secret。它是 secret 的输出结果，会过期；setup key 才是能反复生成动态码的源头，必须当作密码级别的机密对待。

短信验证码、邮件验证码、硬件安全密钥请求、App 内批准通知，都属于不同的登录方式。把它们对应的文本粘贴进这个字段，并不会让它们变成基于时间的一次性密码（TOTP）。字段只认 TOTP 类的 secret。

官方文档特意提醒了两件事：不要把 setup key 粘贴进 AI 对话让模型帮你配置，也不要在用于支持的截图里露出真实的 key。这两条建议背后是同一个逻辑——secret 一旦泄露，等同于把第二因素交了出去。

TOTP（Time-based One-Time Password，基于时间的一次性密码）是 RFC 6238 定义的标准算法。它的核心机制是：客户端与服务端事先共享一段 Base32 编码的密钥（即 setup key），然后双方各自以 30 秒为一个时间窗口，用「密钥 + 当前 Unix 时间戳」做一次 HMAC-SHA1 运算，再截取、取模，最终得到一个六位数字。只要两端时钟一致、密钥一致，算出来的码就必然相同——这也是为什么时间偏移会导致验证失败。与之并列的还有 HOTP（RFC 4226，基于计数器而非时间），以及各类非 TOTP 的验证方式。理解这一点就能明白：secret 是算法的输入，动态码是算法的输出，二者在信息论上不可逆，所以保存动态码毫无意义。

前置准备：账号与 Vault 的状态检查

开始之前，需要装好 OGAD、解锁 Pro Vault，并连接浏览器扩展。然后打开目标账号真实的安全设置页面，先确认域名无误，再考虑修改登录方式。

一个经常被跳过的步骤是：在 setup 完成之前，保留一个仍然可用的登录方式。如果服务商提供了恢复代码（recovery codes），要按一套“电脑或 Vault 不可用”时也能执行的方案单独存放。官方说得直白：验证码生成器本身无法解锁一个被锁住的 Vault，恢复路径必须独立存在。

这套工作流还有一个安全取舍值得点明。当你把密码和验证器 secret 存进同一个登录条目时，两者就位于同一个本地 Vault 里了。这种安排是否符合你的账号要求，需要自己判断——它和“第二因素放在另一台物理设备上”的隔离程度并不相同。

「第二因素」指的是多因素认证（MFA）中独立于密码的那一层凭证。安全模型的关键假设是：密码可能因撞库、钓鱼或数据泄露而失守，因此第二因素必须来自另一个不共享风险的存在。常见的第二因素分为三类——你知道的（密码）、你拥有的（手机、硬件密钥）、你是什么（指纹、面容）。把 TOTP secret 和密码塞进同一个 Vault，本质上是让「你知道的」和「你拥有的」合并成同一个可被一次性攻破的资产：如果 Vault 被解密，攻击者同时拿到两把钥匙，第二因素就退化为单因素。这正是官方反复强调恢复路径必须独立存在的原因——恢复码若也存进同一个 Vault，等于把所有后路压在同一个失败点上。

把 setup key 加进正确的登录条目

具体操作分成六步：

1. 在网站上选择“身份验证器应用”的配置方式
2. 找到服务提供的文本 setup key 或受支持的 otpauth:// 值
3. 在浏览器 Vault 中打开对应的登录条目
4. 编辑 One-time code secret，填入该 setup 值
5. 核对 Websites 和 Username 字段，然后保存
6. 重新打开已保存的条目，用其中当前的 Authenticator code 完成网站的校验

第 5 步的核对环节容易被当成走过场。实际上，同一服务下相似的两条登录记录可能分别对应不同账号，各自生成的动态码长度一样、格式一样，光看“码能出来”并不足以证明它属于你正在登录的那个账号。复制之前确认账号名，是个成本很低但很值动作。

如果网站只给出二维码图片，要优先找它自己提供的“显示文本密钥”选项。当前发布的扩展并不假设能扫描页面上任意一张二维码，官方指南对此保持了明确的边界，没有把 QR 导入当作默认能力来承诺。

后续登录时怎么用这个动态码

登录流程本身和常规 TOTP 没差别：打开真实的登录页面，填入保存的用户名和密码，等网站要求验证器码时，打开登录条目的 Authenticator code，复制当前值填入。

关键在于盯住倒计时。如果当前代码已经接近切换点，等下一个值出来再提交，比赌它能在过期前被服务器验证要稳。部分受支持的表单可以通过 Vault 填充直接接受验证码，但当网站使用非常规的一组输入框时，手动复制仍然是有效的兜底手段。

网站拒绝验证码时的排查路径

官方给出了一张按症状分类的排查表：

症状	检查项	处理动作
输入过程中代码过期	倒计时	等待新值并尽快提交
所有代码都失败	电脑日期与时间	校准时钟后重试新代码
密码正确但验证码错误	账号与 setup key	核对保存的登录条目是否对应此账号
不显示任何验证码	secret 字段与 Vault 锁定状态	检查已保存的 setup 值并解锁 Vault

第二行是最隐蔽的坑：TOTP 的算法核心是本地时钟和服务端时钟的匹配。电脑时间偏了几分钟，本地算出来的码在逻辑上是“正确”的，但服务端会直接判定失效。这类问题在排查时极易被误判为 secret 存错了。

文档还提了一条安全底线：反复失败不是关闭账号登录保护的理由。如果无法完成 setup，走服务商支持的恢复流程，而不是在另一个验证器还能用的情况下随机替换 secret。

TOTP 对时钟的依赖是它最容易被误诊的失效模式。RFC 6238 允许服务端做一定程度的「漂移容忍」，通常是前后各一个 30 秒窗口，也就是约 90 秒的容错范围；但若本地时钟偏差超过这个窗口，生成的码在服务端看来就落在无效区间，表现为「码看起来正常却一律被拒」。桌面系统的时间漂移在长时间休眠、跨时区旅行、虚拟机挂起后尤为常见。排查顺序建议是：先在系统设置里确认时区正确，再强制与网络时间协议（NTP）服务器同步，然后重新生成一个新码提交。同理，若同一 secret 同时存在于桌面 Vault 和手机验证器，两者时钟不一致也会表现为「手机能过、电脑不过」，这时应分别校准两台设备。

“离线”到什么程度？一个需要说清的前提

把 setup secret 存好之后，计算 TOTP 本身确实不需要云 AI 服务，也不需要聊天模型。这部分是纯本地的。

但这个“离线”有边界。首先，本地桌面 Vault 必须能被浏览器扩展访问到；其次，你要登录的那个网站通常需要互联网。所以本地生成动态码，并不意味着整个登录过程是一个离线任务。

时钟问题在这里又出现了一次：代码可以完全在本地算出来，却因为时间不对而失败。锁定桌面 Vault 会切断浏览器对已打开条目的访问；如果电脑不可用，就得走事先准备好的账号恢复路径。文档最后提醒，不要假设这套桌面工作流已经把验证器 secret 复制到了你的手机上——它没有。

otpauth:// 是一个 URI 方案，Google Authenticator 等工具广泛采用，用于把 TOTP 参数打包成一个可传递的字符串，典型格式为 otpauth://totp/发行方:账号?secret=XXXX&issuer=发行方&digits=6&period=30。其中 secret 参数就是 Base32 编码的 setup key，其余参数描述位数、周期和展示名称。它之所以比纯 key 更好用，是因为它把「这个密钥属于哪个账号、哪个发行方」一并编码进去，减少了手动核对时填错条目的概率。需要注意的是，otpauth:// 链接本身不含任何加密，任何能读到这段字符串的人都能据此重建你的验证器——因此在截图、日志或聊天窗口中暴露该 URI，与直接泄露 setup key 的后果完全相同。

从一个可恢复的账号开始

官方建议的起步方式很克制：挑一个你已经验证过恢复方法的账号，在 OGAD 里配置它的登录、保存受支持的 setup key、完成网站验证，然后再测试一次后续登录。确认整条链路走通，再考虑迁移其他账号。

这种渐进式迁移的思路值得借鉴。验证器迁移的风险不在于配置动作本身，而在于失败时你是否还有退路——先在一个有退路的账号上跑通流程，比一次性批量迁移要安全得多。