通行密钥不是「一次性切换」的事情，而是一次有条理的迁移。这份清单把 100 个站点的迁移拆成七个步骤，包含盘点、排序、创建、替换与回滚预案，可以直接照着做。
先想清楚：为什么值得迁移
密码的问题不在于长度，而在于它需要被人在多个网站之间复制、运输和记忆。只要这个动作存在，钓鱼、撞库与暴力破解就永远有机会。通行密钥把「记忆一串秘密」换成了「在一台设备上证明你是你」，跨站点的钓鱼攻击从此失去着力点。
从技术上说，通行密钥建立在 WebAuthn 与 FIDO2 之上：网站（依赖方，RP）注册公钥，认证器保存私钥，登录时用私钥对挑战值签名。因为私钥从不离开认证器，攻击者即便完全控制网页，也无法伪造出一个可用的凭据。
WebAuthn 还提供了一个常被忽视的能力：用户在场（UV）与用户核实（UV）标志。人机在场意味着认证器确认操作者是真人而非自动化脚本，这正是「静默钓鱼攻击」难以得逞的原因。
- WebAuthn 是 W3C 标准，FIDO2 是其中最常见的认证器规范
- 依赖方 ID（RP ID）绑定域名，是防止跨域重放的关键约束
- 人机在场（UV）标志让自动化钓鱼脚本难以奏效
第一步：盘点你的账号
打开源钥的安全报告，把「重复密码」与「旧密码」两类条目先导出来看一眼。这份清单通常会让人生出直观感受：一个普通用户手上平均有 30 到 60 个长期不登录的网站，其中相当一部分还在用同一个密码。
在源钥里为每个站点补齐三项信息：登录用的邮箱或用户名、是否支持通行密钥、这个账号丢了会不会造成实质损失。第三项决定了优先级——把银行、邮箱、主账号放在最前面，把一个十年前注册的论坛放在最后。
盘点时顺手确认一件事：源钥的登录方式本身也要升级。保险库的登录应当优先使用通行密钥，主密码作为恢复手段保留，而不是反过来。
- 从安全报告导出「重复密码」「旧密码」两份清单
- 为每个站点记录：账号、是否支持通行密钥、丢失代价
- 先升级源钥自己的登录，再动其他网站
第二步：排序：先迁哪些
推荐一个简单的三档法。高优先级是金融、邮箱、云服务与社交主账号，它们既是资产入口，也是找回其他账号的钥匙；中优先级是日常高频使用的电商、办公与开发平台；低优先级是长期不用但一旦泄露会造成骚扰的论坛。
还有一个常被忽略的判断维度：这个网站是否已经把通行密钥作为默认登录方式。如果网站支持并且默认开启，那么你没有理由继续使用密码——多留一条密码路径，就多留一个被钓鱼的入口。
不要一次性全量切换。按批次推进，每批控制在 15 到 20 个站点，完成一批就运行一次安全报告，确认没有留下重复项再进入下一批。
第三步：在源钥里创建通行密钥
在源钥客户端里创建一个通行密钥时，流程是标准的 WebAuthn 注册：客户端向网站请求一个随机挑战，认证器生成密钥对，把公钥与签名回传，同时向依赖方证明自己掌握对应的认证器数据（例如通过设备生物识别）。
在 iCloud Keychain、Google Password Manager、Windows Hello 中创建的通行密钥，也可以导入源钥统一管理。导入走的是标准凭据导出交换流程，私钥始终是加密状态迁移的。
源钥作为可同步凭据提供方（synced passkey provider）保存这些凭据，因此换手机时它们跟着走，不需要在每个网站重新注册一遍。同步本身走的是端到端加密：凭据在离开设备前已加密，服务器只搬运密文。
- 支持 FIDO2 / U2F 硬件安全密钥，包括 YubiKey 等常见型号
- 可导入 iCloud Keychain、Windows Hello 等系统密钥库中的通行密钥
- 同步凭据端到端加密，换设备不丢
// WebAuthn 注册的简化时序
challenge = server.nonce()
credential = authenticator.create({ challenge, rp: { id: "example.com" } })第四步：替换密码并清理残留
创建通行密钥之后，去网站的安全设置里把「密码登录」关掉，而不是仅仅新增一种方式。如果两种方式同时保留，钓鱼者依然可以用假页面骗到你的密码——通行密钥的价值恰恰在于把密码这条路彻底堵死。
关闭之后，网站原密码会失效或变成一次性过渡口令。确认通行密钥在至少两个设备上都能正常使用，再彻底删除旧密码条目，否则某天你会在没有手机的情况下被自己锁在门外。
最后运行一次安全报告，检查是否还有指向同一账号的旧密码残留。对已经泄露过或被复用的密码，正确做法是直接丢弃，而不是换一个相似的。
- 关闭密码登录，而不是并列保留两种方式
- 确认至少两个设备可用之后，再删除旧密码条目
- 对已泄露的密码直接换新，不要做「微调式」替换
第五步：回滚预案
任何批量迁移都要留退路。建议在源钥里保留一份「迁移中」集合，把还没切换完的账号集中放在一起，并确保这一批账号至少有一种非通行密钥的登录方式可用（备用通行密钥、硬件密钥或强密码）。
对重要账号，可以先在浏览器里注册通行密钥，验证能登录之后再在手机上注册第二个凭据。两端都通过后，才去网站关闭密码登录。
如果迁移过程中出现登录失败，先别慌着重置密码——重置通常会直接关掉正在配置的通行密钥。先检查依赖方 ID 是否匹配、认证器时间是否准确、WebAuthn 是否被浏览器策略禁用。
- 每批控制在 15–20 个站点，保留一个「迁移中」集合
- 重要账号先注册第二个凭据，再关闭密码登录
- 登录失败先查 RP ID、时间同步与浏览器策略，别急着重置密码
常见陷阱与真实收益
第一个陷阱是「多设备同步不等于备份」。同步凭据依赖你的恢复路径，如果主密码和同步凭据同时丢失，仍然会锁定。至少保留一份打印出来的恢复码，放在你信任的地方。
第二个陷阱是忘掉 WebAuthn 的依赖方 ID 绑定：凭据只能在注册时对应的域名下使用，这是特性而不是限制，跨站复用反而是漏洞。
真实的收益往往比想象中更大：装上通行密钥之后，用弱密码撞库的批量攻击彻底失效，账号被接管的主要路径从「密码库碰撞」变成了「物理接触设备」与「社会工程学」。在钓鱼仍然盛行的环境里，这已经是最有效的单点改善。
- 同步凭据仍然依赖恢复路径，请离线保存恢复码
- 凭据与域名严格绑定，跨站复用是特性还是漏洞取决于你的需求
- 迁移完成后，撞库类攻击对你的账号基本失效
把这篇文章分享给同事
如果你正在推动团队迁移到通行密钥，这篇可能正好用得上。
苏未明
安全负责人
曾在安全厂商做攻防研究，负责漏洞响应、审计与安全白皮书。
关注方向：安全与合规