Passkey 不怕钓鱼却怕设备失守：Google 同步密钥的新攻击面
作者：韩启明｜OC 政策与安全编辑
韩启明
Palo Alto Networks Unit 42 公布了针对 Chrome、Windows TPM 与 Google Password Manager 同步 Passkey 的三类攻击。研究者可以在已经运行恶意软件的电脑上，逐步借用本机密钥、登记攻击者控制的验证密钥，甚至取得用于解密同步凭据的安全域秘密。
一句话结论：Passkey 仍能有效抵御钓鱼和密码复用，但“不可被偷走”不是它的绝对属性；当同步凭据依赖云端恢复、本地进程和设备解锁状态协作时，已经入侵终端的恶意程序会获得新的横向移动空间。
三种攻击都有一个重要前提：攻击者已经能在受害者的 Windows 电脑上运行恶意代码。它们不是远程破解 WebAuthn 密码学，也不代表 Android、iOS 或所有密码管理器都受影响。研究聚焦的是 Google Password Manager 在 Chrome 中调用 Windows TPM 的具体实现。
第一种 Pass-ta-key 攻击读取 Chrome 同步数据库中的站点、用户名、凭据 ID 和加密密钥元数据，再让受害者的 TPM 为云认证请求签名。如果网站没有严格要求并校验用户验证标志，恶意程序就可能在用户没有明确确认的情况下完成登录。研究者称 eBay 在收到披露后修正了相关校验。
第二种 Silver 攻击利用重新加入安全域的流程。研究者强制客户端进入待登记状态，再提交攻击者控制的用户验证密钥；其报告认为云端认证器没有验证这把密钥来自可信设备。登记完成后，攻击者可以离开受害者电脑继续发起认证。
第三种 Golden 攻击影响最大。它尝试取得 32 字节的安全域秘密，用来解密账户同步的 Passkey。Google 已删除一次重登记过程中把秘密写入明文日志的路径，但 Unit 42 表示它仍会短暂存在于 Chrome 内存中，而且目前没有独立轮换或撤销该秘密的公开机制。
Google 的文档仍强调，Password Manager 中同步的 Passkey 使用端到端加密，新设备需要屏幕锁或 Google Password Manager PIN。这些设计提高了门槛，却不能消除已被控制终端上的进程间信任问题。网站也不能把责任完全交给认证器：userVerification 的要求和服务端验证仍是协议的一部分。
关键事实
- 三种攻击都要求恶意程序已在受害者 Windows 设备上运行
- 研究对象是 Chrome、Windows TPM 和 Google Password Manager 云认证器的组合
- 攻击分别涉及本机签名借用、验证密钥登记和安全域秘密提取
- 研究没有证明 WebAuthn 加密算法被破解，也不能外推到全部 Passkey 实现
OC 判断
Passkey 把大规模钓鱼的风险显著压低，却把更多价值集中到设备会话、同步恢复和本地认证器实现。安全宣传应该从“密钥永远无法被盗”改成更准确的描述：凭据不再容易被用户交给假网站，但终端失守后的恢复链路仍必须审计和撤销。
为什么重要
- 对开发者：服务端必须明确请求并验证用户验证状态，不能只确认签名有效。
- 对企业：终端检测和浏览器版本管理仍是无密码登录体系的一部分。
- 对用户：Passkey 可以替代弱密码，但不能替代系统更新、磁盘保护和恶意软件防护。
评论
围绕这篇文章补充信息、提出问题或分享观察。