Passkeys 不是魔法：Pass-ta-key 真正改变了什么

8 月围绕 Pass-ta-key 的讨论，不该让人放弃 passkeys。它真正提醒的是：不要把 passkeys 当成魔法。Unit 42 分析了 Windows 上 Chrome 与 Google Password Manager 同步 passkeys 的攻击面。Ars Technica 的平衡解读很重要：这不是 passkeys 已经失效，而是说明“抗钓鱼”并不等于“已感染设备也安全”。

发生了什么，不该得出什么结论

Unit 42 研究的是具体环境：Google Password Manager、Windows 版 Chrome、cloud authenticator，以及依赖 TPM 的设备信任。三类攻击被称为 Pass-ta-key、Silver Pass-ta-key 和 Golden Pass-ta-key。关键前提是：攻击开始时，受害者设备上已经有恶意软件。这不是远程破解 WebAuthn，也不是钓鱼网页能像偷密码一样偷走 passkey。

更准确的结论是：在这个环境里，本地恶意代码可能滥用浏览器状态、设备加入流程、账号恢复流程，以及 synced passkeys 周围的 user verification 决策。在某些配置下，攻击者可能获得账号访问、绕过预期验证，或取得可利用的同步材料。对实现者和企业安全团队来说这很严重；对普通用户来说，它不等于应该关闭 passkeys。

Ars 的提醒在这里有价值。如果 endpoint 已经被控制，攻击者不仅会盯着 passkeys，也会盯着 cookies、OAuth tokens、浏览器配置、密码库、文件、通知和恢复页面。Passkeys 设计目标是替代共享秘密、抵抗假登录页面。它们不是杀毒软件、EDR、操作系统隔离和事故响应的替代品。

passkey 到底保护什么

Passkey 是基于 FIDO/WebAuthn 的公钥凭据。注册时，authenticator 为某个 relying party 生成一对密钥。服务端保存 public key，private key 留在 authenticator 或 passkey provider 控制之下。登录时，服务端发送 challenge，authenticator 对正确 origin 的数据签名，浏览器返回 assertion。根据策略，用户可能需要解锁设备、输入 PIN、使用生物识别，或触碰安全密钥。

这改变了攻击经济。假登录页拿不到可重复使用的密码。服务器数据库泄露也不会给攻击者可撞库的密码哈希。Credential stuffing 的基础被削弱。FIDO 与 W3C 称其为 phishing-resistant，是因为加密响应绑定到真实 origin，而不是绑定到看起来相似的表单。

但抗钓鱼不是抗恶意软件。它意味着远程假网站不应拿到 reusable secret。它不意味着已感染笔记本不能在受信任浏览器配置内操作、触发已有信任流程、等待用户解锁、读取本地状态，或滥用活动会话。安全承诺都有边界。Passkeys 的边界很有用，但不是无限。

Unit 42 给出的实际教训

Unit 42 3 月文章解释了 Google Cloud Authenticator 背后的机制；8 月文章展示了 Windows 版 Chrome、本地同步数据、TPM 和设备信任如何形成新的假设。范围必须说清楚：Google Password Manager in Chrome on Windows with TPM，负责任披露，并且攻击以设备上已有 malware 为前提。

第一课是设备信任不能变成盲目信任。攻击代码如果已经运行在浏览器和 Google 账号所在环境，就可能试图让某些步骤看起来来自合法上下文。第二课是 user verification：高风险账号和操作不应随意停在 preferred。第三课是同步：同步 passkeys 对普通用户很有价值，因为它减少丢设备后的灾难和回到弱密码的诱因，但 recovery、backup 和 onboarding 也因此变成安全边界的一部分。

这并不说明所有人都该禁用 synced passkeys。对普通消费者，它们通常比密码加短信更安全。对管理员、财务人员、代码维护者和高价值账号，硬件安全密钥、受管设备、conditional access 与严格注册流程更合适。

普通用户该怎么做

继续在重要账号上使用 passkeys。给所有能批准登录的设备设置强屏幕锁。删除账号安全页面里的旧手机、旧电脑和旧浏览器。检查恢复邮箱和手机号，因为账号恢复常常是 passwordless 之后的薄弱门。不要在共享或不可信电脑上登录主邮箱、银行、开发者账号或云控制台。

谨慎安装浏览器扩展。拥有广泛权限的扩展离页面、提示和会话太近。保持操作系统和浏览器更新。如果设备中过 malware，把清理当成身份安全事件：撤销 sessions，检查新增 passkeys，移除未知设备，查看邮件转发规则和 OAuth 授权。只删除恶意文件而不检查账号状态，风险仍然存在。

对最重要的账号，使用硬件安全密钥，并准备第二把备用钥匙。它没有同步 passkey 方便，但能减少对普通桌面状态和云同步的依赖。它也不是魔法：恢复流程、客服流程和登录后的设备安全仍然重要。

组织该怎么做

企业部署前要先分类。哪些员工主要面对大规模 phishing？哪些人可以改 identity policy、付款、部署生产系统或读取受监管数据？哪些设备受管、加密、打补丁并被监控？允许哪些 passkey providers？哪里可以接受同步，哪里必须使用 hardware keys 或 managed devices？

普通员工账号使用 synced passkeys，往往比密码和短信好得多。特权账号可能需要硬件密钥、设备合规、管理工作站和临时提权。还要分清两条研究线：Unit 42 讲的是 Google synced passkeys、Chrome 与 Windows；SpecterOps/Microsoft Entra 讨论的是 WebAuthn、Windows 11、assertion logging 与 replay validation。它们不是同一个漏洞，但共同说明实现细节决定结果。

事件响应也要改变。endpoint 被入侵时，只重置密码不够。要撤销 sessions、移除设备、检查最近新增的 passkeys、轮换恢复因素、检查 OAuth grants、重新注册可信设备并阅读登录日志。Passwordless 需要 passwordless 事故预案。

平静结论

Passkeys 没有死，也不是魔法。它们显著优于密码，因为日常登录不再依赖可重复使用的共享秘密。它们降低 phishing、credential stuffing 和密码复用风险。它们不能消除 malware、薄弱 recovery 和糟糕 WebAuthn 实现。实用规则很简单：普通账号继续用 passkeys；高风险账号用硬件密钥和受管设备；服务端把 WebAuthn 当协议认真实现；同时保持设备干净。