通行密钥虽好，但没人告诉你隐患，等发现时为时已晚

大约一年前，我在手机上创建了我的第一个通行密钥，有一阵子，我觉得登录问题总算解决了。面容解锁基本上秒进；无需输入任何内容，也无需记住任何新东西。后来，我在手机不可用的情况下，用借来的笔记本电脑和不同的浏览器尝试登录，那种丝滑体验就开始崩了。

我倒没被锁在外面，但它让我看到，一旦存着凭证的设备不可用，这种便利消失得有多快。通行密钥免去了在受支持的登录过程中输入密码的需要，但它们并没有消除账户恢复。它们把大部分责任甩给了存着凭证的设备、凭证提供商和云账户。

通行密钥用起来无感，直到换了设备才发现问题

便利是有存储位置的，不管你知不知道

当网站问你要不要创建一个通行密钥时，你的浏览器或操作系统通常会建议存储位置，尽管可用选项取决于你的设备、已启用的提供商以及网站的政策。凭证提供商是存储并在某些情况下同步通行密钥的操作系统服务或密码管理器。当密码管理器让通行密钥可见且可管理，而不是把它们埋在系统的弹窗里时，这个存储层就变得容易理解多了。

然后你用指纹、面容 ID、PIN 或者 Windows Hello 验证一下身份，无需输入密码即可登录。每个通行密钥都属于某个特定的网站或应用账户，所以它不是那种一把钥匙开所有锁的万能钥匙。

创建一个通行密钥会生成一对密钥。网站存储公钥，而对应的私钥材料还是归你的设备或凭证提供商管。支持同步的提供商可以把端到端加密的副本发到你的其他设备上，但网站永远不会收到私钥。

实际区别在于同步通行密钥和设备绑定通行密钥这两种类型。保存在 iCloud 钥匙串中的通行密钥会跟着你走，在受信任的 Apple 设备上都能用，而 Google 密码管理器会在 Android 设备和支持的 Chrome 浏览器之间同步通行密钥。设备绑定通行密钥则只留在一个验证器上。Windows 上的 Microsoft Entra 通行密钥目前是预览功能，它把凭据存在本地的 Windows Hello 容器里，而且每台 PC 都需要单独注册。

不同提供商之间的可迁移性也在改善。FIDO 联盟的凭据交换规范为参与的应用提供了一个安全标准，用来传输凭据（包括通行密钥）。较新的 Apple 平台已经支持这类传输，Google 密码管理器现在也支持在 Android 上和兼容的管理器互相导入导出通行密钥。不过麻烦的地方还没消失，因为能不能用仍然取决于当前的软件版本，而且需要双方提供商都参与。

当通行密钥存储在手机上而不是你面前的电脑上时，跨设备认证可以补上这个缺口。笔记本电脑显示二维码，你的手机扫描它，蓝牙会确认两台设备离得够近，然后才批准登录。在这种情况下，你的 Android 手机实际上就是你面前这台设备的安全密钥。

实际请求通过端到端加密的互联网连接传输，手机对一次性的验证请求进行签名，而不会交出通行密钥本身。如果手机超出了蓝牙范围、离线了、用不了，或者落在家里了，这条路也就断了。

手机丢了还能接受，但恢复涉及两个层面

通行密钥或许安然无恙，但它关联的账户可能已经出大问题了

如果你的通行密钥通过端到端加密的提供商进行了同步，那么手机掉进湖里，通常还有办法找回。在新设备上登录就能恢复。Apple 为 iCloud 钥匙串提供了受保护的恢复机制。与此同时，Google 可能要求提供 Google 密码管理器 PIN 码或现有设备的屏幕锁定，才能在新设备上使用已同步的通行密钥。

实际上存在两个恢复问题。第一个是凭据恢复，即恢复包含你通行密钥的加密存储库。第二个是网站账户恢复，即在没有可用通行密钥的情况下重新进入某个具体的服务。

如果你的同步数据存在 Apple、Microsoft、第三方或 Google 账户上，而你又登不进这个账户，凭据恢复可能会变得困难甚至不可能。当唯一的通行密钥只存在丢失的那台设备里、当你在未先转移凭据的情况下更换提供商、或者公司配的电脑不让你用你想用的那个服务商时，同样的风险也会出现。

此时，恢复就完全看这个服务还提供哪些备用方式，可能是密码、电子邮件链接、恢复代码、另一个已注册的通行密钥，或某个支持流程。这并不意味着每一种备用方式都不安全，但它意味着这个账户实际抗接管的能力，可能就取决于它允许的最弱的那个恢复方式。

通行密钥可以抵御钓鱼攻击，但一个暴露的电子邮件账户仍会开辟另一条入侵路径。被劫持的、用于短信认证的手机号码也能起到同样的作用，前提是服务允许将其作为恢复途径。

我的通行密钥现在有了退出方案

我现在会在关门之前先检查紧急出口

我仍然会创建通行密钥，不过在点击确认之前，我会更仔细地考虑每个通行密钥到底存在哪里。对于真正重要的账户，只要网站允许，我通常会用不同的设备或服务商再注册一个备用通行密钥。替代手动输入密码的硬件安全密钥也是极佳的备份手段，前提是别和手机放在同一个包或同一个口袋里。

我还会把恢复代码放在别处，不放在它本来要替代的那台设备上，并确保同步我通行密钥的账户仍然拥有可用的恢复选项。这一原则同样适用于安全备份密码管理器保险库：如果备份就放在它要救的那台设备或那个账户旁边，那这备份基本没什么用。

在换掉旧手机或删掉备用密码之前，我会先去看看网站的通行密钥管理页面。每个服务对通行密钥的处理方式都略有不同。有些会重命名它们，有些会显示更多信息，而从服务商那边删掉通行密钥，并不代表网站上对应的注册记录也会被删掉。

最能给我信心的习惯，恰恰也是最不起眼的。在清空旧设备之前，我会从另一台设备登录，确认一切正常，并且在替代设备完全配置好之前，留一个安全的备用方案。这会多花几分钟，但这远比已经被锁在外面了、才发现恢复计划有漏洞要好得多。

只要你清楚它们存放在哪里，通行密钥依然非常出色

我并没有要放弃通行密钥。当一项服务把它实现到位时，在我关心的几乎每一个方面，它们都胜过密码，从方便程度到防钓鱼能力都是如此。薄弱的环节从来不是密码学本身，也不是日常登录体验。问题出在底层的机制上，包括同步账户、凭据提供商、设备生态系统和恢复路径，这些都很容易被忽略，直到手机坏了，或者平台一变、逼着你去面对它们。

一旦你搞清楚自己的通行密钥存在哪里、通过什么进行同步，以及在没有常用设备的情况下怎么恢复访问，隐藏的隐患就好处理多了。