导入后先核对条目数量、名称与分组

在将验证码数据从其他身份验证器迁移至安令码,或通过兼容格式导入备份文件后,第一步并非立即开始使用,而是进行严格的完整性核对。由于不同服务对账户命名的规范不一,需要确认导入后同名账户的归属、分组与条目范围是否符合预期。因此,用户应在导入完成后,首先统计当前列表中的验证码条目总数,并与导出前的原始记录或备份清单进行比对。如果数量不一致,先核对导出时选择的范围和备份时间,再检查导入提示;不只凭数量差异就认定发生格式错误或条目被跳过。

除了数量核对,还需逐一检查每个条目的名称显示是否正确,特别是那些在不同平台拥有相同邮箱或用户名的账户。例如,个人 Gmail 与工作 Google Workspace 账户可能显示为相同的用户名,若未加区分,后续登录时将难以辨别。同时,检查系统是否自动保留了原有的分组标签。若导入后所有账户均处于“未分组”或默认状态,用户需手动介入,为每个账户重新分配明确的分组标识,这是防止后续混淆的基础步骤。

风险边界在于,若在条目数量不符或分组标签缺失的情况下直接清理旧设备或卸载原应用,一旦新设备上的数据存在隐性错误,用户将面临无法登录关键账户的风险。因此,核对阶段必须保持旧设备或原备份文件的可用性,直到所有条目确认无误且经过真实登录测试。

  • 核对导入后的条目总数是否与导出前一致,差异需立即排查。
  • 检查每个同名账户的显示名称是否包含足以区分的后缀或前缀。
  • 确认分组标签是否完整保留,缺失时需手动补全。
  • 在确认无误前,严禁删除旧设备上的验证器应用或备份文件。

用搜索与分组区分工作、个人与开发账户

安令码提供了搜索、分组和排序能力,这是解决同名账户混淆的核心工具。面对多个名称相同但归属不同的账户(如多个名为“Admin”的服务器账户),用户应建立一套标准化的分组命名体系。可以按需要使用“工作”“个人”或“开发测试”等名称,不必创建固定数量的分组,也不假定支持嵌套子组。通过为每个同名账户打上明确的分组标签,按当前界面的分组入口查找对应条目,可以减少逐条辨认的范围;具体交互以正式版本说明为准。

使用搜索与分组时,先核对结果中是否包含预期账户。公开产品页介绍了这些能力,但没有确认搜索一定只作用于当前分组,也未列出按最近使用时间排序或置顶的规则。可以尝试当前版本实际提供的排序选项,再检查常用账户是否更容易找到;不要把一种设想的组合操作写成固定界面步骤。

分组是整理条目的方式,不会把一个账户变成另一个账户,也不能替代验证参数或恢复凭据。产品介绍本地加密保险库,并不足以推导分组信息在所有备份或传输场景下绝不会离开设备。若需要了解数据保存与同步范围,应查看对应功能说明,不能据此作完整的不上传保证。

  • 按用途选择自己容易辨认的分组名称。
  • 核对搜索和分组后的实际结果,不预设组合规则。
  • 只使用当前版本提供的排序方式。
  • 分组不代替验证参数或账户恢复凭据。
安令码安全与备份原创概念界面,展示本地加密、生物识别、加密导出和自动备份

同名账户的 TOTP 时间步长与参数核对

对于基于时间的一次性密码算法(TOTP),RFC 6238 规定生成端与验证端必须使用一致的共享密钥及时间步长,并能获取当前 Unix 时间。RFC 中三十秒是默认时间步长,不代表所有服务的固定配置;具体参数按对应服务说明核对。当存在同名账户时,若其中一个账户的时间步长配置错误,生成的验证码将无法通过服务端验证,导致登录失败。因此,在整理同名账户时,必须逐一核对每个账户的 TOTP 参数,确保其与账户服务提供商的要求完全一致。

核对过程包括确认共享密钥是否正确录入,以及时间步长设置是否符合服务规范。如果在添加账户时是通过扫描二维码完成的,通常参数会自动配置;但若是手动输入密钥,则需格外注意步长设置。若发现验证码持续无效,且排除时间同步问题后,应怀疑参数配置错误。此时,需重新查看服务提供商提供的设置页面或二维码信息,确认正确的时间步长,再按当前版本支持的方式和服务指导处理,不自行猜测或反复改动密钥。

此外,RFC 6238 还规定同一时间步长内生成的 TOTP 值相同,且验证端在一次成功验证后,不得再次接受该时间步长内的同一验证码。这意味着用户在使用同名账户时,若在短时间内多次尝试登录,可能会遇到验证码已失效的提示。理解这一机制有助于用户避免因重复提交同一验证码而产生的困惑,重复操作时先核对该账户是否已成功用过当前码,再按对应时间步等待下一码,而不是反复刷新。

  • 核对每个同名账户的 TOTP 时间步长,确认是否为默认的 30 秒或服务指定的其他值。
  • 验证共享密钥与服务端记录一致,特别是手动添加的账户。
  • 理解同一时间步长内验证码不可重复使用的规则,避免重复提交。
  • 若验证码无效,优先检查时间步长和密钥配置,而非立即重置账户。

HOTP 同名账户的计数器同步检查

与 TOTP 不同,基于计数器的一次性密码算法(HOTP)依赖于递增计数器和共享密钥,RFC 4226 指出计数器必须在生成端与验证端保持同步。对于使用 HOTP 的同名账户,计数器失步是导致验证码无效的常见原因。这种情况通常发生在用户连续生成了多个验证码但未提交给服务端,或者在网络不稳定时多次点击生成按钮。由于计数器是单向递增的,生成端的计数器值若超过服务端预期的窗口范围,生成的验证码将被拒绝。

怀疑 HOTP 失步时,先停止无目的地生成和提交新码,并查看账户服务的重同步说明。RFC 讨论服务端有限窗口的重同步,但没有规定用户应连续试码来碰中窗口。安令码中看到的计数状态不能代替服务端信息;具体是否需要提供连续验证码及其操作顺序,应由该服务的明确流程决定。

若自行尝试无法解决,需联系账户服务提供方进行计数器重置或重同步。在此过程中,用户应避免随意删除或重新添加账户,因为这可能导致计数器彻底重置,进一步加剧失步问题。对于重要的 HOTP 账户,建议在添加时记录初始计数器值,并在日常使用中避免无谓地生成验证码,以减少失步风险。

  • 连续生成未提交的码可能让 HOTP 计数器超前。
  • 怀疑失步先停止无目的地生成,查看服务的重同步说明。
  • 不自行连续试码或删除账户来重置计数器。
  • 保留现有条目与必要记录,按服务指导处理。
从账户安全设置到完成第二步检查的通用教育流程图,非产品截图

加密导出与备份的独立密码设置

整理完成后,可以按安令码说明准备加密导出,用于保存和迁移实际导出的验证码条目。使用独立、可靠的导出密码,并与文件分开保管。导出密码和保险库解锁密码用途不同;这种安排用于降低凭据同时暴露的风险;文件与密码仍需分别妥善保管,并按实际保存位置核对访问权限。

用户应选择一个高强度且易于记忆的导出密码,并将其与导出文件分开保管。例如,可将导出文件存储在加密的云存储或物理介质中,而将导出密码记录在密码管理器或纸质笔记中,切勿将两者放在同一位置。备份更新后,记录对应的时间和密码用途,确认自己仍能找到适用的文件与凭据。自动备份功能的具体触发条件及保存方式以正式版本说明为准,用户应关注官方发布的最新指引。

如果文件和解密密码放在同一位置,该位置失守时可能同时暴露两者。因此,分开保管的同时也要确认日后可访问,不把主要的密码记录遗失。备份能恢复哪些内容取决于当时保存的范围;改过分组或新增账户后,应核对这些变化是否已进入需要使用的备份。

  • 使用独立、可靠的导出密码,并区分保险库解锁用途。
  • 文件与密码分开保管,核对日后可访问性。
  • 备份更新后记录时间和对应凭据。
  • 检查实际条目范围,不默认包含后续所有更改。

恢复后完成重要账户的真实登录验证

备份的最终目的是恢复,恢复后需要同时核对条目范围与实际可用性。因此,在将备份文件导入新设备或重新安装安令码后,用户不应仅满足于看到条目列表恢复原状,而必须执行真实登录验证。选择几个关键账户(如邮箱、银行、主要社交平台),使用生成的验证码完成一次完整的登录流程。这一步骤不仅能验证验证码生成的正确性,能帮助检查已经测试的条目,不证明全部数据均完整或从未被修改。

只有在确认所有重要账户均能成功登录后,再安排旧设备的后续处理;仍有保留价值的原备份不应因为一次测试成功就删除。若在验证过程中发现某个账户无法登录,应立即停止清理操作,回溯检查该账户的配置参数或重新从服务提供商处获取新的密钥。真实登录验证是迁移流程中的最后一道防线,它能有效避免因隐性错误导致的账户锁定风险。

此外,CISA 提醒用户,身份验证器生成的一次性验证码虽是多因素验证的常见方式,但并非抗钓鱼验证方式。因此,在登录验证时,务必确认访问的是官方网站,避免在钓鱼网站上输入验证码,导致凭据泄露。

  • 对重要账户完成真实登录,核对实际可用性。
  • 未验证完成前保留旧设备与备份,不删除主要恢复副本。
  • 发现失败先核对账户和参数,再按服务说明处理。
  • 输入验证码前确认正确的服务与登录页面。

区分账户恢复码与验证器备份

账户恢复码由具体服务提供,其生成、使用次数和替换规则以该服务为准,常用于备用验证或账户恢复。验证器备份则用于恢复实际保存的条目,两者不是同一种凭据。备份只能反映保存时的范围,不能保证含有之后新加的所有账户;恢复码也不能解密这份备份。

如果验证器不可用但仍有该账户的有效恢复码,可按服务流程查看是否能恢复访问并重新绑定。若缺少恢复码或备份,应核对该服务还有哪些已设置的备用方式,不能直接断言账户永久无法登录。日常应将账户恢复资料与验证器备份分别整理,并明确每份资料属于哪个账户或哪次导出。

在整理同名账户时,建议为每个重要账户单独存档其恢复码,并与验证器备份文件分开管理。这种双重保障策略能最大程度降低因单一备份失效而导致的账户丢失风险。

  • 明确账户恢复码用于恢复账户访问,验证器备份用于恢复验证器条目。
  • 两者不可互相替代,需分别妥善保管。
  • 为每个重要账户单独存档恢复码,并与验证器备份分离。
  • 定期检查恢复码的可用性,确保在紧急情况下可使用。

生物识别解锁与保险库密码的备用方案

安令码支持使用密码或生物识别(如指纹、面部识别)解锁本地加密保险库,提升了日常使用的便捷性。然而,生物识别技术受限于硬件状态、系统更新或用户生理变化,可能出现无法识别的情况。安令码备份说明提醒,即使启用了生物识别,用户仍必须记住保险库密码。这是因为在设备更换、生物传感器故障或系统重置等场景下,仍可能需要保险库密码,具体以实际界面和正式版本说明为准。

用户应定期测试密码解锁流程,确保在生物识别不可用时能顺利进入应用。建议将保险库密码记录在安全的离线介质中,或存储在另一台可信设备的密码管理器内,避免遗忘。同时,不要将保险库密码设置为过于简单的组合,以免被暴力破解。

如果保险库密码和生物识别暂时都无法使用,先保留现有设备与备份,再核对适用的处理方法。加密导出文件需要其对应的导出密码,不能把保险库解锁失败直接等同于所有备份无法恢复。当前产品说明没有给出全部密码遗忘场景的恢复结论,不宜据此作永久丢失或一定可恢复的承诺。

  • 启用生物识别后仍应记住保险库密码。
  • 按实际入口核对密码解锁方式。
  • 分清保险库与导出文件所需的密码。
  • 遇到访问问题先保留数据,再查适用处理方式。