Passkey 新漏洞：恶意软件可绕过验证
Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
Palo Alto Networks 的 Unit 42 团队揭示了 Passkey 无密码认证中的新型攻击面。研究指出，即使在没有提权、无需解锁设备或用户交互的情况下，运行在受害者设备上的恶意软件也能利用 Google 的同步 Passkey 机制接管账户。攻击者通过提取设备身份密钥，伪造签名欺骗 Google Cloud Authenticator，甚至能绕过生物识别验证。这种被称为 Pass-ta-key 的攻击手段，包括 Silver 和 Golden 变种，不仅暴露了云端认证架构的潜在弱点，还意味着攻击者可以提取并转卖所有同步的 Passkey 私钥。随着无密码认证的普及，防御者必须警惕这些针对新认证范式的威胁。
攻击者不会消失，他们会进化，而防御者必须为新一代的攻击做好准备。
- sandeepkd
有助于提高意识，但这完全不是什么新发现。这是一家特定公司发布的片面、耸人听闻且不完整的公关稿。
1. 这里没有任何新东西，这是一种已知行为，且已在公共领域存在一段时间了。
2. 文章谈到了可同步的 Passkey，却未能讨论与此主题核心相关的“可备份（Backup eligible）”和“备份状态（Backup state）”概念。
3. Passkey 的核心卖点是抗钓鱼能力，而文章对此只字未提。
4. Authenticator 的实现给实施方提供了很大的灵活性，但也留下了被滥用的空间。这里存在易用性（在设备间同步凭证）与安全性之间的权衡。
5. 它本质上只是一个被美化过的受管密码，具备抗钓鱼能力，因此仍然是比单独使用密码好得多的选择。
- amluto
这触及了我对 TPM 的一个主要痛点：TPM 只关心全局设备状态，完全没有考虑到设备可能是多用户系统、拥有不同安全级别的多进程、存在多个租户等情况。
例如，理应能够密封一个密钥，使其只能在 PCRs 具有特定值（这是 TPM 的常规操作）且请求解封操作的主体被操作系统（软件 TCB）标记为具有特定身份时才能解封。TPM 规范中完全缺失了后半部分。（该身份可以是进程的哈希值、UUID，或任何能与相关进程合理关联的其他内容。显然这里存在一些细微差别。）
如果 TPM 能按我期望的方式工作，那么与 Chrome 并行运行的非特权进程将完全无法利用 TPM 来冒充 Chrome。
- tptacek
这些是端点恶意软件攻击，并非针对 Passkey 本身的攻击。攻击者一旦处于这种境地，游戏就已经结束了。
- MBCook
天哪，我真是受够了人们试图发明各种花哨的攻击名称。它们无助于记忆，而且数量太多了。
所以，所有这 3 种“pass-ta-key”攻击都不是针对 Passkey 的攻击，而是针对 Google 保险库的攻击。
如果你能访问保险库，那你就得到了一切。好吧。如果你能访问同步的传统密码保险库，你也得到了一切。
所以……也就那样吧。这些都是漏洞，会被修复的。感谢他们披露了这些漏洞。但这并不能证明 Passkey 很糟糕。这也不会让它们比随机密码更不安全。
如果不是因为它们恰好涉及 Passkey，这些漏洞似乎根本不值得上头条或讨论。而且，如果攻击者拥有这种级别的访问权限，他们也能获取保险库中所有的标准密码凭证，对吧？
- colemannugent
>4. 使用该握手的哈希值，攻击者与受害者的 TPM 交互，并使用提取的身份密钥对握手哈希值连同断言请求进行签名
哈？如果你拥有这种级别的本地权限，难道不能直接从浏览器存储中读取会话 Cookie 吗？我猜窃取所有密钥确实值得注意，但拥有这种访问权限时，你难道不能操纵任何密码管理器吗？
这里的威胁模型是什么？难道同步的 Passkey 在客户端被入侵的情况下也应该保持安全吗？怎么做到的？