你以为通行密钥已经够安全了

如果你已经开始使用通行密钥（Passkey），你大概会觉得：太好了，钓鱼网站再也骗不到我了。

这个想法对了一半。

通行密钥的设计确实从根本上解决了钓鱼攻击的核心问题——它使用非对称加密，私钥永远留在你的设备上，不会像密码那样被输入到伪造的网站里。WebAuthn标准还将凭证绑定到了合法的域名，所以即使攻击者搭建了一个以假乱真的登录页面，也无法 replay 你的通行密钥。

但这是建立在”你的设备是安全的”这个前提上的。一旦你的设备被恶意软件控制，事情就开始变得复杂了。

同步通行密钥带来的新攻击面

设备绑定型 vs 同步型

通行密钥有两种存在形式：设备绑定型（device-bound）和同步型（synced）。

设备绑定型的通行密钥只存在于单个设备上，不从设备A复制到设备B。它的优点是完全隔离，缺点是换设备后所有通行密钥都要重新设置。

同步型的通行密钥通过密码管理器（如Google Password Manager、1Password、Apple iCloud Keychain）在不同设备之间同步。它牺牲了一些隔离性，但换手机或换新电脑时不再需要重新配置每个账户的通行密钥。

基础设施的扩大

当你把通行密钥同步到云端或密码管理器时，整个认证链条中被引入的基础设施变多了：浏览器、操作系统、凭据管理器、设备注册、账户恢复流程、同步机制。每一个新增的环节都是潜在的攻击入口。

Unit 42的”Pass the Passkey”研究

2026年8月，Palo Alto Networks的Unit 42研究团队发表了一份报告，详细演示了三种针对同步通行密钥的攻击方式。这些攻击有一个共同前提：你的电脑上已经运行了恶意软件。

这个前提很重要——Unit 42的研究不是教你怎么远程窃取通行密钥，而是在你已经中招的情况下，攻击者能走多远。

Pass-ta-key（通行密钥传递）

这种攻击利用了Chrome的设备身份机制。恶意软件不需要提取通行密钥的私钥，只需要利用Chrome的设备身份来生成一个密码学上有效的认证断言。在GitHub的测试中，由于用户验证未被满足，攻击失败；但在eBay的测试中，攻击在修复前成功通过。

更严重的是Silver变体——它利用了设备重新注册机制，注册了一个攻击者控制的验证密钥，之后可以在另一个环境中使用该密钥进行认证。

Golden Pass-ta-key（黄金通行密钥传递）

这是最接近传统”凭据窃取”概念的攻击。Google的同步通行密钥实现使用了一个32字节的Security Domain Secret（SDS）来保护私钥。Unit 42发现，在注册过程中，SDS会以明文形式出现在Chrome的FIDO设备日志中。

虽然Google在研究人员报告后移除了这个日志暴露，但Unit 42发现SDS在设备注册或恢复期间仍然会短暂出现在Chrome进程内存中。恶意软件如果能在设备通过注册流程时捕获Chrome内存，就能提取SDS，然后用它解密账户中存储的所有同步通行密钥私钥。

更危险的是：一旦SDS被窃取，它可以解密该账户的所有现有通行密钥，以及未来创建的新通行密钥。而Google的当前实现在SDS泄露后没有提供轮换或撤销的机制——清理被感染的电脑并不能自动使攻击者手中的SDS失效。

为什么这个研究改变了我的看法

过去我把”抗钓鱼”和”抗窃取”混为一谈。Passkey的设计确实让钓鱼攻击变得不可能——伪造的登录页面无法收集到任何可用的凭据。但Unit 42的研究揭示了一个更微妙的事实：即使加密机制本身完美无缺，围绕同步通行密钥构建的整个基础设施仍然存在攻击路径。

我现在的思路是：把浏览器、操作系统、凭据管理器、恢复流程都算作通行密钥设置的一部分。这意味着我需要更认真地对待恶意软件防护，更频繁地更新Chrome，更警惕异常的设备恢复提示。

如何保护自己

优先使用硬件安全密钥

对于高价值账户（邮箱、银行、工作系统），如果服务支持，优先使用物理安全密钥（如YubiKey）。硬件密钥实现了真正的设备绑定，私钥永远不会离开物理设备，避免了同步带来的所有风险。

警惕异常的设备恢复提示

Unit 42指出，Google Password Manager的恢复PIN提示通常只出现在设备注册或账户恢复过程中。如果你在正常使用通行密钥时突然收到这样的提示，要保持警惕。这可能意味着有人正在尝试触发恢复流程。

认真考虑备份认证器

对于你特别看重的账户，可以考虑使用设备绑定的通行密钥作为主认证方式，同时配备一个独立的备份认证器，并安全存储账户恢复代码。这需要更多的管理成本，但对于高价值账户是值得的。

保持系统更新

确保Chrome、操作系统和安全软件始终是最新版本。Unit 42的发现已经被Google修复，但浏览器的安全更新频率直接影响你面对新漏洞时的防护能力。

了解你账户的恢复机制

很多账户被盗事件的发生，不是因为通行密钥本身被破解，而是因为攻击者通过社会工程学或钓鱼手段绕过了账户恢复流程。确保你的账户恢复方式足够安全。

通行密钥仍然值得用

说这么多，并不意味着你应该放弃通行密钥。相对于密码，通行密钥在抵御钓鱼攻击方面仍然有压倒性的优势。Unit 42的研究揭示的是锦上添花的改进方向，而不是否定通行密钥本身的价值。

关键在于转变思维：不要认为通行密钥是”设好就不用管了”的终极解决方案。它是一个强大的工具，但它的安全保障依赖于整个生态——浏览器、操作系统、密码管理器、设备本身——每一环都不能掉链子。

写在最后

安全领域的经验反复证明了一件事：再好的单一防御措施也有盲区。通行密钥解决了密码体系的核心弱点，但没有解决所有问题。了解它的局限性，采取额外的防护措施，才能在钓鱼攻击和凭据窃取之间建立起真正的双重保障。

核心风险：同步通行密钥在设备注册和恢复过程中可能暴露Security Domain Secret，恶意软件可据此解密所有同步的通行密钥私钥。核心措施：对高价值账户使用硬件安全密钥替代同步通行密钥，保持系统和浏览器更新，警惕异常的设备恢复提示。管理建议：将通行密钥安全纳入企业身份治理策略，明确不同账户类型的认证方式要求。