通行密钥的「注册」才是新的攻击面：Pass-the-Passkey 对身份提供商配置意味着什么

通行密钥（Passkey）的卖点简单，而且属实：没有任何可供钓鱼的东西。不存在一串可以被诱导输入到仿冒域名里的字符。对于过去十年不断因凭据钓鱼丢失账户的企业来说，仅此一条就足以推动迁移。

然后在2026年8月初，两支彼此独立的研究团队在不到48小时内相继公开成果，改变了这句话在实务层面的含义。两者都没有攻破密码学本身，而是绕了过去——并且都落在同一个位置：凭据被注册的那一刻。

如果你正在运营或规划集中式身份基础设施，这部分值得仔细读。应对措施几乎全部是配置问题，而且大部分位于身份提供商侧，而不是终端。

8月究竟发生了什么

Unit 42，8月3日。 研究员 Arie Olshtein 公开了针对 Google Password Manager 同步通行密钥的三条攻击链，均通过 Chrome 在 Windows 上使用的云认证器实现。三条链的前提相同：恶意软件已经以普通用户权限运行在机器上——不需要管理员权限，受害者屏幕上不会出现任何提示。

第一条链冒充受信任设备与 Google 云认证器交互，直接取得有效的认证断言，全程不触碰指纹传感器、不输入 PIN。第二条链滥用设备重新注册流程：恶意软件使现有的验证密钥失效，或删除本地凭据状态文件，强制 Chrome 重新完成上机流程，并在此过程中注册属于攻击者自己的用户验证密钥。此后攻击者可以直接从自己的机器登录，无需再接触受害者设备。第三条最为严重，它抓取重新注册期间短暂出现在 Chrome 进程内存中的 32 字节安全域密钥。仅这一个值就能解密该账户下所有同步通行密钥的私钥，包括之后新建的，而目前没有任何机制可以在其泄露后进行轮换或吊销。

这三条链未分配 CVE 编号。Google 已发布部分缓解措施。

SpecterOps，8月5日，Black Hat USA。 Michael Grafnetter 发布了一组刻意以 Pass-the-Hash 命名逻辑对应的攻击。最严重的一条链结合了两个弱点：Windows 11 会将完整的 WebAuthn 断言响应写入运行日志，而已通过认证但不具特权的用户——在某些配置下甚至是远程用户——可以读取该日志；与此同时 Microsoft Entra ID 对这些响应的校验不够严格，无法拒绝重放。两者叠加，攻击者可以在完全满足「抗钓鱼 MFA」强制要求的前提下，冒充特权云身份。同一份研究还发现硬件令牌的历史签名以明文形式存放在非特权账户可读的位置。

微软在2026年7月14日的更新中以 CVE-2026-34348 修复了日志侧问题，将写入日志的签名部分截断至6字节——够用于排障，不够用于重放。SpecterOps 认为在已打补丁的系统上，从 Windows 到 Entra 的完整攻击链已被切断。

结构性结论：风险转移到了「注册」环节

在密码时代，秘密本身就是资产。窃取它，重放它。我们构建的所有防御——定期更换、复杂度规则、MFA、不可能旅行关联分析——都建立在一个前提上：攻击者的目标是获取用户已经持有的东西。

在通行密钥时代，这个目标基本失效了。设备绑定的私钥不会离开认证器，通行密钥也无法被钓鱼。于是攻击者的问题从我怎么窃取他的凭据，变成了我怎么让系统给我签发一个。

Silver Pass-ta-key 是最清晰的例证。攻击者从未拿到用户的密钥，他只是通过系统本就为此提供的流程，添加了自己的密钥。这不是凭据窃取，而是凭据签发——而且它具备被窃密码从未有过的持久性，因为它能挺过通常用来终结事件的密码重置与会话吊销。

身份提供商只在两个时刻接受新的认证器：初次注册，以及恢复或重新注册。在多数部署中，这两个时刻恰好是整个身份体系里监控最薄弱、策略管控最松的操作。

flowchart TD
    A["凭据注册"] --> B["日常身份验证"]
    B --> C["恢复或重新注册"]
    C --> A
    A --> D["攻击者注册自己的认证器"]
    C --> D
    B --> E["从日志中截获断言并重放"]
    C --> F["在重新上机过程中提取同步主密钥"]
    D --> G["能挺过密码重置的持久访问"]
    E --> G
    F --> G

由此得出的结论令人不适但很清楚：你的无密码体系的强度，恰好等于最薄弱的那条注册路径。 如果服务台人员凭一通电话就能为财务总监的账户绑定新的认证器，那你拥有的只是一套穿着通行密钥外衣的密码重置流程。

中国市场必须并行考虑的几点

这几条会改变上述判断在国内环境中的权重。

同步生态不同，问题不变。 Google 的同步通行密钥体系在境内基本不适用，因此 Unit 42 那三条链的直接暴露面较小。但结构性教训适用于任何同步型凭据体系——包括微信、钉钉、飞书以及各类国产密码管理器所承载的凭据同步能力。真正需要问的问题不是「我们用不用 Google」，而是「哪些系统有权为一个已有身份签发新凭据，以及这个动作被谁审批过」。

等保2.0 的身份鉴别要求。 三级及以上系统对身份鉴别有双因素要求，而测评关注的从来不只是「登录时验了几个因素」，还包括鉴别信息的管理与更换过程是否受控、是否留痕。为特权账户新增认证器却没有审批记录和告警，在测评中属于可被判定为不符合项的管理缺陷。新增认证接口或改动认证架构，也可能触发等保定级与备案的边界重新评估。

PIPL 与《数据安全法》下的取证要求。 当攻击者使用以员工名义正规注册的凭据进入系统，调查的第一个问题必然是「访问了哪些个人信息、从什么时候开始」。如果没有每个认证器的注册时间与来源记录，这个问题在合规要求的响应时限内无法回答。凭据清单因此不只是安全措施，更是事前就必须准备好的证据链。

数据不出境与国密适配。 如果认证基础设施承载境内业务的身份数据，将特权身份的信任完全托付给境外云的同步机制，在数据出境合规评估中是需要正面回答的问题。自建 IdP、凭据数据留在境内、并在需要时适配 SM2/SM3 算法体系，通常比依赖境外同步生态更容易通过评估。

需要在身份提供商上完成的六项配置

一、把「注册」当作特权操作对待

许多租户的默认设置是：任何已通过认证的会话都可以注册额外的认证方式。想想这意味着什么——一枚被盗的会话 Cookie，原本会自然过期，现在被转化为一个永久注册的凭据。

把注册动作放在会话 Cookie 单独无法满足的条件之后——受管且合规的设备、最近几分钟内完成的阶梯式验证、已知的网络范围，或由管理员显式开启的注册窗口。在 Entra ID 中，这是认证方法策略加上针对「注册安全信息」这一用户操作的条件访问规则。在 Authentik 中，这意味着建立拥有独立 Stage 与 Policy 的专用注册流程，而不是让常规登录流程顺带完成新设备绑定。

需要牢记的原则只有一条：授权添加新凭据的那个凭据，强度至少不应低于被添加的凭据。

二、不要把「用户已验证」标志当成有人在场的证据

依赖方普遍把断言中的用户验证位当作有人触摸了传感器或输入了 PIN 的证据。Unit 42 的发现是：被攻陷的认证器可以在无人触碰任何东西的情况下把这一位置为真。

在你自己拥有依赖方的系统里，请校验完整断言而不是读取一个布尔值：来源域、挑战值的新鲜度、签名计数器行为，以及认证器型号标识与白名单的比对。在你不拥有依赖方的场景——也就是大多数 SaaS——补偿性控制只能放在身份提供商侧，即从源头限制哪些型号的认证器被允许注册。

三、同步型与设备绑定型按等级区分，而不是全局一刀切

同步通行密钥是通行密钥能够普及的原因，恢复体验才让普通用户真正用得起来。但它同时意味着一个云账户量级的爆炸半径，而 Golden Pass-ta-key 表明同步背后的主密钥目前没有吊销手段。

一个站得住脚的划分是：面向大量普通内部应用，同步型凭据没有问题；面向管理员角色、财务系统，以及一切能够划转资金或修改身份配置的系统，要求注册时通过认证器证明的设备绑定硬件认证器。用注册环节的认证器证明与型号白名单来强制执行，因为制度文档拦不住一个注册请求。

四、恢复通道才是你真实的安全水位

人会丢手机，所以任何无密码部署都保留了回退方案：短信验证码、邮件魔法链接、服务台重置、临时访问通行证。

如果回退方案能够签发一个新的通行密钥，那么无论主方案是什么，回退方案就是你的认证强度。攻击者十年来一直直取恢复通道，主通道变难之后没有任何理由认为这一点会改变。

具体做法：把临时访问通行证的签发限制在一个具名的小范围内，短有效期、一次性使用，并且每一次签发都触发告警。服务台发起的重置必须通过一条来电者不可能已经掌控的渠道核验身份——这就排除了与该账户绑定的邮箱和手机号。

五、建立凭据清单，然后监控它的变化

多数组织回答不了关于自己认证器的基本问题：这个用户有几个、每一个是什么时候注册的、来自哪台设备和哪个位置、其中哪些还在实际使用。

先把这份清单做出来。然后对真正有意义的模式设置告警——来自新国家或地区的注册、第一个凭据之后几分钟内添加的第二个、工作时间之外的注册，以及持有特权角色的账户上的任何凭据变更。这些应当呼叫值班人员，而不是躺在事后才被翻阅的审计日志里。

离职处理也属于同一范畴。SCIM 停用事件需要同时作废会话并移除已注册的凭据。一个被停用但认证器仍然绑定在上的账户，就是一次等待发生的重新启用——而这正是集中式身份层本应封堵的那类缺口。

六、确认七月的补丁真的打上了

CVE-2026-34348 于2026年7月14日发布。从 Windows 到 Entra 的重放链依赖于该补丁的缺失。请核查全网部署情况，并特别关注管理工作站与跳板机——它们既是价值最高的目标，在很多组织里也恰恰是最容易被排除在标准补丁环之外的机器。

加固后的注册流程长什么样

flowchart TD
    U["用户申请注册新的认证器"] --> P1["检查设备是否受管且合规"]
    P1 --> P2["要求完成新的阶梯式验证"]
    P2 --> P3["核对认证器证明与型号白名单"]
    P3 --> T["评估账户等级"]
    T --> H["特权等级必须使用设备绑定硬件密钥"]
    T --> S["普通等级允许使用同步通行密钥"]
    H --> L["记录注册事件并告警"]
    S --> L
    L --> R["完成凭据注册并录入清单"]

如果你同时还负责检测

上述注册侧的控制才是治本的做法。如果你同时运营终端遥测体系，有三个信号能够直接对应 Unit 42 的手法，值得加入规则集：来自未签名或异常二进制文件的浏览器内存进程访问、由非浏览器进程创建或删除的浏览器凭据状态文件，以及非浏览器进程对浏览器同步数据库的读取。在 Sysmon 环境中，这些对应事件 ID 10 与 11，外加标准的文件访问遥测。

在身份侧，应当从审计日志提升为告警的事件包括：认证方式的注册与移除、临时访问通行证的签发、认证器证明校验失败，以及触及特权角色的任何凭据变更。如果你已经在运行基于 Wazuh 的监控体系，这些只是新增日志源，而不是新增工具。

本周就能做完的一次简短审计

1. 列出租户中所有能够注册新认证器的路径，包括服务台的人工流程，而不只是技术流程。
2. 针对每条路径，写下一个仅持有被盗有效会话、别无其他的攻击者需要突破什么。
3. 检查注册是否受设备合规性与新完成的阶梯式验证约束，还是仅凭已有会话即可通过。
4. 导出所有持有管理员角色账户的凭据清单，排查来自异常设备或异常时间的注册记录。
5. 确认哪些恢复方式可以产生新的通行密钥，以及谁有权触发它们。
6. 专门核验管理工作站上 CVE-2026-34348 的补丁状态。
7. 检查离职流程是否移除凭据而不只是会话，用一个真实账户实测一次。

常见问题

我们是否应该停止推行通行密钥？

不应该。通行密钥消除了凭据钓鱼，而钓鱼至今仍以巨大优势位居最常见的初始入侵手段。8月的研究没有改变这一点。它改变的是「部署了通行密钥，身份工作就完成了」这一假设——工作被转移到了注册、恢复与凭据清单，而它本来就应该在那里。

如果我们不使用 Google Password Manager，还会受影响吗？

Unit 42 的具体攻击链针对 Windows 上 Google 的同步通行密钥生态，在境内的直接暴露面有限。但结构性教训适用于任何同步型凭据体系，而 SpecterOps 的攻击链直接针对 Windows 11 与 Entra ID。如果你的员工通过 Microsoft 365 认证，应当优先阅读的是后一份研究。

硬件安全密钥现在还值得投入吗？

对特权账户而言，值得。带认证器证明的设备绑定凭据仍是现有最强的选项，同步主密钥的问题对它并不适用。8月的研究确实发现硬件令牌签名暴露在 Windows 日志中，但那是打补丁的理由，不是放弃硬件令牌的理由。

我们是没有专职身份团队的中型企业，应该从哪里开始？

从注册门槛和恢复通道开始。这两项控制封堵了实务上的大部分风险，而且都不需要采购新软件——它们是你已经在运行的身份提供商上的配置变更。凭据清单排在其后，因为你无法对一件从未清点过的事物的变化设置告警。

集中到单一身份提供商，会不会因为风险集中而更糟？

集中的是控制点，这与风险集中恰好相反。有24套独立登录系统，就有24组注册与恢复路径，其中大多数从未被审计过。只有一个身份提供商时，需要加固的是一组路径、需要维护的是一份清单、需要执行吊销的也只有一个地方。

---

这篇文章的位置

上述一切的前提是身份的集中化。在每个应用各自管理登录的分散环境里，你无法为注册设置门槛、无法按等级强制认证器证明、也无法维护一份凭据清单——这正是集中化本身的理由。

Simplico 构建并运营 simpliSSO：一个基于 Authentik、与 Microsoft 365 及 Azure AD 联合的身份门户，覆盖 OIDC、SAML2、LDAP、阶梯式 MFA 策略，以及面向全部应用资产的 SCIM 自动预置。无论你是在既有部署上推进注册流程加固，还是在为新项目界定范围，我们都乐意看看你的环境：hello@simplico.net

---

来源:

• Pass the Passkey: A Novel Attack Surface in Passwordless Authentication — Unit 42
• New Passkey Attacks Can Recover Synced Private Keys or Bypass Phishing-Resistant MFA — The Hacker News
• New Pass-ta-key attacks let malware hijack Google-synced passkeys — BleepingComputer
• Flaws in Passkey Implementation Show Old Attacks Still Work — Dark Reading
• Pass-the-Passkey Family of Attacks at Black Hat USA 26 — DSInternals