Pass-ta-key：针对 Google 通行密钥的攻击究竟意味着什么

通行密钥难道并没有我们以为的那么安全吗？Pass-ta-key 提出的正是这个问题。

Palo Alto Networks Unit 42 描述了三条攻击链。恶意软件可以利用它们滥用由 Google 同步的通行密钥、绕过用户验证，并在最严重的场景下提取某个账号的全部通行密钥私钥。

这三种技术都没有攻破 WebAuthn、FIDO2 或其采用的公钥密码学。它们都要求恶意软件已经在受害者的 Windows PC 上运行。这是一个很大的限制。

尽管如此，用“端点已经被攻陷，反正什么都没了”来分析还是过于草率。Golden Pass-ta-key 试图把一次本地入侵变成一套能够长期使用、可以导出的全部同步通行密钥。它的影响因此超出了窃取单个浏览器会话。

先说简短结论

是的，这是一个新颖且独立的安全议题。但它不是废弃通行密钥或重新只使用密码的理由。

正确的理解是：

• 协议依然可靠： Origin Binding、Challenge-Response 和非对称密码学均未被攻破。
• 受到攻击的是具体实现： 受影响的是 Unit 42 所研究的 Google Password Manager、Chrome、Windows 与 TPM 的组合。
• 端点必须已经被攻陷： 这不是互联网上任意网站都能对一台干净计算机发起的攻击。
• 潜在损失仍然严重： 不同攻击从悄然生成登录 Assertion，到提取全部同步通行密钥的私钥。
• 同步通行密钥与设备绑定通行密钥的风险特征不同： 两者都是通行密钥，但安全级别并不相同。
• 密码仍然是更差的替代方案： 它还会遭到钓鱼、重复使用、猜测以及服务器数据库窃取。

因此，我的风险评估不是“什么也没发生”，而是：技术适用范围较窄，前置条件也很苛刻，但一旦成功执行，潜在影响可能非常高。

技术范围与证据

截至 2026 年 8 月 31 日，可确认的资料包括 Unit 42 记录的攻击流程、WebAuthn 规范、Google 的通行密钥文档、公开可见的 Chromium Issue，以及 NIST 当前对可同步 Authenticator 的要求。此外，SpecterOps 的 Pass-the-Passkey、CVE-2026-34348、Proofpoint 的 FIDO 降级，以及 Expel 和 SquareX 的技术发现，也都是评估攻击面的依据。

该研究于 8 月 3 日发布，Unit 42 在 8 月 14 日进行了更新。它明确针对配备 Trusted Platform Module 的 Windows 设备上，Chrome 中的 Google Password Manager。其他浏览器、操作系统与通行密钥提供商可能存在类似的架构问题，但这三种攻击尚未在它们上面得到证明。

目前没有证据表明，这些特定技术已经出现在真实环境中的活跃攻击活动里。现阶段的证据来自研究、Proof of Concept 与 Responsible Disclosure。这一点对于风险评估很重要：技术上得到演示，并不自动意味着它已被大规模利用。

通行密钥究竟保护什么

通行密钥并不是特别长的密码。它是基于非对称密码学的 WebAuthn 凭据。

注册时，Authenticator 会生成一对密钥：

private key -> remains with the authenticator
public key  -> is registered with the online service

在线服务在 WebAuthn 中被称为“Relying Party”，它会将公钥与 Credential-ID、用户账号一起保存。之后登录时，服务发送一个全新且随机的 Challenge。Authenticator 对数据进行签名，其中包含对该 Challenge 以及发起请求网站上下文的绑定。服务器使用已保存的公钥验证签名。

因此，私钥不会像密码那样传给服务器。在理想情况下，服务发生数据泄露时，攻击者只能得到公钥，无法用它生成有效签名。

绑定 Relying-Party-ID 和 Web-Origin 同样关键。用于 example.com 的通行密钥不会在一个极其相似的钓鱼域名上生成可供 example.com 使用的有效 Assertion。用户手中没有可以在错误网站输入，或通过电话念给攻击者的秘密。

这正是抗钓鱼的含义。NIST 对该术语的定义很严格：欺诈性的 Verifier 既不能取得认证秘密，也不能取得可用于真实服务的认证响应。WebAuthn 通过与 Verifier 名称建立密码学绑定实现这一点。

这个性质在 Pass-ta-key 中依然完好无损。恶意软件没有搭建更出色的钓鱼网站。它已经运行在用户当作可信 Authenticator 使用的设备上。

User Presence 与 User Verification 并非一回事

要理解这三种攻击，需要区分两个 WebAuthn 信号：

• User Presence，UP： 用户触发了表示其在场的操作，例如触摸 Security Key 或确认对话框。
• User Verification，UV： Authenticator 在本地验证了用户，例如通过 Windows Hello、PIN 或生物识别。

WebAuthn Assertion 将这些结果作为 authenticatorData 中的标志。服务器不能只相信它在登录开始时所提出的要求。如果要求 userVerification: "required"，还必须在响应中检查 UV 标志是否真的被设置。

这一个检查点十分重要。Unit 42 无法成功完成针对 GitHub 的简单 Pass-ta-key 攻击，因为缺少所需的 User Verification。对于 eBay，尽管已经要求 User Verification，登录最初仍然成功。eBay 在收到报告后修复了服务器端检查。

两者的差异说明，从密码学角度正确的签名并不总是足以构成正确实现的多因素认证。Relying Party 还必须验证 Authenticator 实际确认了哪些安全条件。

同步通行密钥为何会形成额外的信任区域

设备绑定通行密钥保留在特定 Authenticator 上，例如 Hardware Security Key 或本地受保护的平台 Authenticator。同步通行密钥则需要在多个设备上可用。为此，它的私钥材料必须以加密形式备份，经由 Sync 基础设施传输，并能在其他已授权设备上恢复。

这不是一个很小的实现差异。同步扩展了整个系统：

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

每一个新增层级都需要自己的设备信任、Onboarding、Recovery、密钥加密与吊销规则。

因此，NIST 明确把可同步 Authenticator 视为独立类别。它们可能适用于最高达到 Authentication Assurance Level 2 的场景。对于 AAL3，NIST 则要求位于硬件保护环境或独立 Authenticator 中、不可导出的密钥。这并不意味着同步通行密钥很弱，而是便捷性与密钥可移植性会形成不同的 Assurance 模型。

Pass-ta-key 瞄准的正是这片额外的信任区域。

研究的准确适用范围

Unit 42 列出了多个在大量新闻标题中未得到充分体现的前提条件：

• 受影响的同步通行密钥由 Google Password Manager 管理。
• Chrome 在 Windows 上运行。
• 设备配有 TPM。
• 恶意软件已经在受害者的用户上下文中运行。
• 用户已经配置在相应的 Chrome 与 Google 环境中。
• 对于部分攻击，恶意软件必须读取本地 Chrome 数据、修改状态文件或检查 Chrome 进程内存。

研究并没有展示适用于所有通行密钥的通用攻击，也没有证明远程攻击者无需先攻陷端点，就能直接从 TPM 中取出 WebAuthn 密钥。

所以，“通行密钥已被破解”是错误的表述。准确的说法是：Unit 42 演示了三条攻击链，它们针对已被攻陷的 Windows 端点上 Google 同步通行密钥的信任、Onboarding 与 Recovery 机制。

阶段零：本地通行密钥地图

根据 Unit 42 的说明，在三种攻击开始之前，恶意软件都会读取本地 Chrome Sync 数据库。其中存有 WebauthnCredentialSpecifics 记录，包含 Relying Party 信息、用户名、Credential-ID 以及加密的私钥材料等内容。

研究给出的路径是：

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

测试中，访问这些记录不需要提升权限。虽然私钥材料并非直接以明文存在，但元数据会向恶意软件提供目标清单：哪些服务拥有通行密钥、它们属于哪些账号，以及需要指定哪个 Credential-ID。

从 Detection 角度看，这本身就很重要。Infostealer 不再需要猜测目标。它可以先建立清单，再有选择地攻击高价值账号。

Pass-ta-key：无需用户操作的有效 Assertion

第一种攻击滥用了 Chrome 用来向 Google Cloud Authenticator 证明 Windows 设备身份的设备密钥。

Chrome 为此生成一个由 TPM 支持的 Identity Key。Unit 42 解释说，Chrome 不会把私钥保存为普通明文密钥，而是通过 Windows CNG 将其导出为 NCRYPT_OPAQUE_KEY_BLOB。TPM 保护这个 Blob，使它能在同一个物理 TPM 上重新导入并用于密码学操作。

这种设计在密码学上是合理的，但并不会自动解决授权问题。研究表明，普通用户上下文中的恶意软件能够读取已保存的 wrapped_identity_private_key，或从 Chrome 内存中取得它，并调用常规 Windows CNG 函数。TPM 随后执行签名，因为从技术上看，请求来自正确的设备。它并不知道调用 API 的是 Chrome 还是恶意软件。

简化后的流程如下：

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

在这种攻击里，通行密钥的私钥文件不一定会被导出。恶意软件把被攻陷的设备与 Google Cloud Authenticator 当作签名服务使用。

它的天然限制是 UV 标志。Identity Key 可以证明设备持有，但不能证明 PIN 或生物识别检查成功。一个正确实现、强制要求 User Verification 并检查结果的服务，必须拒绝 UV = 0 的 Assertion。

这并不会让该攻击变得无害。许多服务出于兼容性或 UX 原因，只把 User Verification 配置为 preferred。另一些服务虽然提出要求，却错误地检查响应。在这些情况下，原本设想为多因素的登录实际上变成了一个因素：对设备身份的访问。

Silver Pass-ta-key：攻击者注册自己的 UV 身份

Silver Pass-ta-key 绕过了刚才所述的限制。攻击者并不试图攻破 Windows Hello 或受害者的生物识别，而是让 Cloud Authenticator 今后接受攻击者自己的密钥，作为 User Verification 的有效证明。

起点是 Re-Onboarding 流程。研究称，恶意软件可以让 Cloud Authenticator 忘记当前设备状态，或在本地删除 passkey_enclave_state 文件。下一次通行密钥操作时，Chrome 必须重新注册设备。

在 Windows 上，User-Verification-Key 不一定在第一步就创建。Chrome 可以先使用 Google-Password-Manager-Recovery-PIN 并设置 uv_key_pending 状态。真正的 UV-Key 会在下次使用通行密钥时添加。这个针对易用性优化的中间状态打开了攻击窗口。

在准备阶段，受害者必须完成意外触发的 Recovery 或 Re-Onboarding 步骤，并输入 GPM-PIN。恶意软件不需要窃取这个 PIN，只需利用随后形成的 uv_key_pending 状态。之后的恶意登录不再需要任何进一步交互，受害者设备也不必在线。

攻击者在自己的环境中生成密钥对，并把公钥作为新的 UV-Key 发送。Unit 42 的结果显示，Google Cloud Authenticator 在此过程中没有验证新密钥是否确实来自可信硬件。系统将攻击者的密钥与合法设备身份并列保存。

从这一刻起，攻击者可以自行使用私钥签署请求。Cloud Authenticator 把它们视为在本地完成了 User Verification，并生成设置了 UV 标志的 Assertion。此后的登录不再要求受害者 PC 在线。

公开可见的 Chromium Issue 将此行为描述为“GPM Passkeys Are Vulnerable to User Verification Key Abuse”。在我检查时，它被标记为 WAI。无论内部如何评估，这个案例都表明一项重要的架构原则：绑定新的可信密钥的 Recovery 或 Onboarding 流程，本身就是高度关键的认证操作。

Golden Pass-ta-key：Cloud Sync 变成可导出的密钥材料

Golden Pass-ta-key 是最严重的一种攻击。它以 Security Domain Secret，简称 SDS，为目标。这个 32 字节的秘密保护 Google Password Manager 账号内同步的通行密钥私钥。

其架构承诺可以简化为：Client 只持有加密的 wrapped_secret。解密在 Cloud Authenticator 中利用设备专用密钥完成。即使 Client 上存在恶意软件，按设计也不应轻易取得通行密钥私钥。

然而在 Onboarding 与 Recovery 过程中，Sync 基础设施必须重新把设备加入 Security Domain。Unit 42 发现，Chrome 此时会以 Client 能够访问的形式取得 SDS。最初，它甚至出现在 Chrome 的 FIDO 诊断日志里。Google 在收到报告后删除了这项日志输出。但在该流程中，SDS 仍会进入 Chrome 进程内存。

因此，Golden Pass-ta-key 并不是任何时间都能执行的普通内存转储。恶意软件首先要强制进入安全敏感的 Onboarding 或 Recovery 路径，还必须抓住 SDS 出现在 Chrome 进程中的时刻。这增加了攻击难度，但成功提取后，并不会缩小被盗秘密的适用范围。

这条攻击链由多个步骤组成：

1. 恶意软件强制执行一次新的 Onboarding。
2. 等待本地 Enclave 状态重新创建或改变。
3. 在合适的时刻读取 Chrome 进程内存并寻找 SDS。
4. 把 SDS 与之前读取的 Sync 记录结合起来。
5. 解密其中包含的通行密钥私钥。
6. 之后，一个独立于受害者设备的攻击者 Authenticator 就能生成有效 Assertion。

这就是它与被盗 Session-Cookie 在性质上的区别。Session 会过期，也可以由服务器端吊销。Golden Pass-ta-key 则试图导出所有已同步通行密钥的私钥。Unit 42 还写道，同一个 SDS 也保护未来创建的同步通行密钥，而且在所研究的架构中，没有明显的方式可以轮换或吊销这个 SDS。

这项陈述描述的是被研究的 Google 实现现状。它并不能证明每一家通行密钥提供商都使用相同的 Master Key 结构，也不能证明 Google 今后无法修改架构。

本地恶意软件并不会让这项攻击变得无关紧要

能够在一台已登录 PC 的用户上下文中运行任意恶意软件的攻击者，本来就有许多更简单的攻击方式。他可以窃取 Session-Cookie、读取浏览器内容、篡改交易、外传文件，或直接在活动账号中冒充用户。任何认证方式都无法无条件信任一台完全被攻陷的 Client。

这种基本攻击类型也并不新鲜。从被攻陷的 Password Manager 与浏览器中窃取秘密或活动 Session，多年来一直是 Infostealer 的工具之一。Pass-ta-key 并不会把一次既有的 Endpoint 侵害神奇地变成远程攻击。

尽管如此，将该攻击视为无关紧要仍然过于片面。研究提供了此前并非不言自明的、具体且与实现有关的发现：

• 一个无特权进程能够使用绑定 TPM 的 Chrome 设备密钥进行签名。
• 设备持有与用户验证之间的边界，取决于 Relying Party 是否正确评估 UV 标志。
• Re-Onboarding 状态允许注册由攻击者控制的 UV-Key。
• 核心 Sync 秘密最初出现在日志中，之后据研究仍可从进程内存中获取。
• 最严重的路径让同步私钥能够在原始设备之外重复使用。
• 多个合法设备会使用同一个 Credential，因此同步通行密钥常常缺少传统签名计数器，无法将其作为可靠的 Cloning 信号。

“Endpoint 已被攻陷”是前提条件，但并不是对损失的完整描述。在 Incident Response 中，攻击者只偷到一个临时 Session，还是掌握了能长期用于大量服务的私钥材料，差别十分巨大。

Pass-ta-key 只是新攻击面的一部分

Pass-ta-key 并非孤立出现。2025 年与 2026 年的研究展示了多条路径，攻击者不必从数学上攻破私钥，也能削弱通行密钥的保护效果。

在滥用 Sync 与 Recovery 时，Pass-ta-key 要求 Windows Endpoint 上已经运行恶意软件。Pass-the-Passkey 则将对日志中 Assertion 的访问，与服务器端 Replay 缺陷结合起来。FIDO 降级只需要额外启用一条可被钓鱼的登录路径，而 Passkeys Pwned 要求恶意 Browser Extension，或浏览器上下文中的 Script 执行。最后，Infostealer 不会攻击通行密钥本身，而是从被攻陷的浏览器或 Endpoint 中窃取已经认证的 Session。

这些路径都没有攻破公钥密码学。它们的共同点是攻击 WebAuthn 周围的某个信任层：Sync 与 Recovery、服务器端验证、浏览器，或登录后的 Session。

这一区别并非字面上的争论。如果协议被攻破，所有符合规范的实现都会从根本上受到质疑。这里所述的案例则需要在 Endpoint、浏览器、Identity 与服务器端采取不同对策。

Pass-the-Passkey：有效 Assertion 可以被再次使用时

SpecterOps 在 Black Hat USA 2026 前识别出 Windows 11 与 Microsoft Entra ID 中的三项漏洞，以及由它们衍生出的 20 多种攻击技术。最重要的攻击链始于一个意想不到的位置：Windows 把完整的 WebAuthn Assertion 记录到了 Event Log Microsoft-Windows-WebAuthN/Operational。

这种 Assertion 包含 Credential-ID、Challenge、Authenticator Data 与签名等内容。它不是私钥，在 Verifier 正确实现的情况下，应该只能使用一次，而且只能用于对应的登录 Session。然而 SpecterOps 发现，Entra ID 会在有限的时间窗口内再次接受已记录的 Assertion。两个错误由此相遇：

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

Windows 侧问题获得了 CVE-2026-34348 编号。Microsoft 于 2026 年 7 月 14 日发布更新，把记录的签名缩短到几个字节，从而消除了 Replay 来源。另外，某些 FIDO2 Security Key 新增了服务器端签名计数器检查。不过，签名计数器不是普遍适用的防护。有些平台 Credential 与同步 Credential 始终返回零，或者在多个设备之间共享状态。

技术教训并不止于这条已经被切断的 Exploit Chain。WebAuthn Assertion 不应进入诊断日志或 Event Log。Challenge 必须随机、短期有效、只使用一次，并绑定到具体登录 Session。单凭有效签名，并不能证明整个登录流程都是正确的。

另一种攻击技术涉及 Windows WebAuthn API 的 Parent-Window-Handle。本地进程可以安排一个真实的通行密钥对话框，让它在视觉上看起来属于浏览器或邮件客户端等可信程序。这里的 System UI 同样是真实的，但发起它的上下文可能误导用户。因此，用户应该像对待意外的 MFA Push 通知一样，对待意外的通行密钥与 Windows Hello 请求。

最弱的 Fallback 决定真实安全级别

Proofpoint 在 2025 年演示了针对 Microsoft Entra ID 的 FIDO 降级。一套经过修改的 Evilginx Flow 伪装成不支持 FIDO 的浏览器。目标平台随后提供其他登录方式。如果受害者选择 SMS、OTP 或其他可钓鱼方式，认证信息与 Session 就能在 Adversary-in-the-Middle Flow 中被截获。

该攻击没有绕过 Origin Binding。它让 WebAuthn Ceremony 从一开始就不发生。只有账号在通行密钥之外还允许较弱的方式时，这种攻击才会生效。目前没有记录表明这种降级已在真实环境中被利用。

这给企业带来一条令人不舒服但非常清晰的规则：并不是注册了通行密钥，策略就具备抗钓鱼能力。只有当相应保护需求下的登录不再接受可钓鱼的替代路径时，它才真正抗钓鱼。Recovery 与 Helpdesk Reset 也必须纳入同一项评估。

浏览器属于安全模型的一部分

SquareX 以 Passkeys Pwned 为名，展示了恶意 Browser Extension 或浏览器上下文中的 Script 执行，如何干预 navigator.credentials.create() 与 navigator.credentials.get() 的调用。注册过程尤其值得注意：如果攻击者能在正确时机注入自己的密钥材料，用户可能看到真实的生物识别对话框，但后台绑定的却是由攻击者控制的 Credential。

这项研究来自一家安全供应商，不应被等同于普遍存在的浏览器 Exploit。它要求的前提已经很高：Extension 或 Script Context 必须能够置身 WebAuthn 路径之中。不过，架构教训仍然有效。Browser Extension、Content Script 与合法的 WebAuthn Proxy 功能都是 Trusted Computing Base 的组成部分。因此，在托管环境中使用 Extension Allowlist，并控制高权限 Browser API，属于 Identity 防护，而不只是浏览器卫生。

通行密钥保护登录，但不会自动保护之后的 Session

成功登录后，Web 服务通常继续使用 Session-Cookie 或 Token。如果 Infostealer 从浏览器中窃取这个 Session artefact，而服务器又允许它从其他设备重复使用，攻击者既不需要密码，也不需要通行密钥。他攻击的是已经通过认证的 Session。

如今，这比许多前述研究型 Proof of Concept 更具现实可行性。通行密钥显著缩小了登录前与登录过程中的攻击面，但它无法取代安全的 Token 存储、短暂且与风险匹配的 Session 有效期、关键操作重新认证、Token 吊销，以及尽可能将高价值 Session 通过密码学方式绑定到所用设备。

因此，在 Session 窃取中使用“MFA 被绕过”这一说法往往会造成误解。MFA 已经成功完成，被盗的是它之后产生的结果。

PoisonSeed 说明研究多快会变成炒作

Expel 在 2025 年 7 月最初报告了一项所谓针对通行密钥 Cross-Device Authentication 的攻击。攻击者据称可以通过钓鱼页面，把一个合法 QR Code 转发给受害者，从远程接管登录。几天后，Expel 公开撤回了核心说法并道歉。

后续分析显示，Cross-Device Authentication 所设计的本地邻近性检查并没有被成功突破。缺乏所需的邻近性时，流程会超时，所有 MFA 尝试都会失败，攻击者无法获得访问权限。

这个案例对今天的讨论格外有用。听起来可信的 QR Code、钓鱼与通行密钥组合，并不一定就是有效的 FIDO Bypass。良好的安全沟通必须区分观察到的 Account Takeover、可以复现的 Proof of Concept、理论攻击与已经被否定的假设。

我的安全评估

Pass-ta-key 的技术适用范围有限。该攻击链只在配有 TPM 的 Windows 系统上、Chrome 中的 Google Password Manager 上得到证明。由于恶意软件必须已经在本地运行，而且根据具体攻击还要有针对性地修改状态或进程内存，发生可能性处于中等到较低水平。

但潜在影响却很高，甚至非常高。成功攻击可能导致 Account Takeover、持久的远程访问，或多把私钥被提取。WebAuthn、Origin Binding 与公钥密码学均未被攻破，所以协议风险仍然较低。

对于普通用户，同步通行密钥通常仍然比搭配 SMS 验证码或 TOTP 的密码更安全。它从许多现实攻击路径中消除了钓鱼、Credential Stuffing 与可重用密码数据窃取。

对于特权管理员、财务审批、Production 访问或高度监管的系统，这一笼统结论并不足够。组织应当有意识地判断，同步通行密钥是否达到所需的 Assurance Level。设备绑定的平台密钥或单独的 FIDO2 Hardware Key，可能更适合为这些账号划定边界。

这并不是对 Sync Passkey 的否定，而是一种分级安全架构。

Web 服务运营方必须检查什么

对于 Relying Party，最重要的教训并不奇特，而是正确执行 WebAuthn 验证。

服务器应当：

• 在用例确实要求本地 User Verification 时设置 userVerification: "required"；
• 强制检查 authenticatorData 中返回的 UV 标志；
• 完整验证 Challenge、Origin、Relying-Party-ID 与签名；
• 随机生成每个 Challenge，设置短有效期，只接受一次，并绑定到具体 Session；
• 不要让完整 Assertion、签名及其他可重用认证 artefact 进入日志；
• 将通行密钥注册、删除与 Account Recovery 作为高风险 Event 记录；
• 只有在强力重新认证后，才允许为特权账号添加新的 Authenticator；
• 尽可能记录 Authenticator 的来源与特征；
• 对高安全场景考虑 Attestation 与托管 Authenticator；
• 将异常设备变更、地域变更与新的通行密钥绑定纳入 Identity Telemetry；
• 在高风险变更后吊销 Session，并对关键操作重新认证；
• 在平台与应用能够可靠支持后，采用设备绑定 Session。

成熟的 WebAuthn 库可以降低不完整自研实现的风险，但不会免除运营方检查其配置的责任。eBay 案例说明，仅仅一个未被评估的标志就会降低预期安全级别。Pass-the-Passkey 还表明，即便签名正确，如果 Challenge 与 Session 没有正确对应，也会失去意义。

企业应当怎样调整通行密钥部署

通行密钥项目常被当作 IAM 项目规划。Pass-ta-key 表明，它同时也是 Endpoint、浏览器与 Recovery 项目。

对于普通员工账号，同步通行密钥仍然是合理选择。它可以减轻 Helpdesk 工作量，并非常有效地保护用户免受钓鱼侵害。但对于特权角色，策略应当根据保护需求做出明确区分。

普通用户账号可以在托管设备上使用同步通行密钥，并结合 Endpoint Protection 与 Conditional Access。对于敏感业务账号，托管平台 Authenticator 或受到限制、具有更强设备绑定的 Sync 环境更为合适。Admin、Break-Glass 与其他高价值账号应使用独立的设备绑定 FIDO2 Hardware Key、严格控制的 Recovery，并禁止不受控的 Cloud Sync。

此外，企业还应当：

• 保持 Chrome 与 Windows 为最新版本；
• 检查 Windows 针对 CVE-2026-34348 的安全状态；
• 通过 Enterprise Policy 有意识地允许或限制内置 Browser Manager 保存通行密钥；
• 使用 Allowlist 管理 Browser Extension，并监控高权限 WebAuthn Proxy 功能；
• 让 EDR 与 Application Control 也覆盖用户进程；
• 监控对 Browser Sync 数据库的访问，以及 Chrome 进程内存的转储；
• 调查 passkey_enclave_state 被删除或意外重新创建的情况；
• 把重复或意外出现的 Google-Password-Manager-Recovery-PIN 请求视为警报信号；
• 测试现有设备丢失与 Account Recovery 流程能否被滥用；
• 为特权账号移除可钓鱼 Fallback，或通过 Authentication-Strength-Policy 将其排除；
• 调查意外的通行密钥提示、新的 Credential 注册，以及来自异常进程的 WebAuthn 使用；
• 盘点哪些重要服务使用同步 Credential，哪些使用设备绑定 Credential。

组织层面的关键点是：Endpoint Detection 并不是与通行密钥项目无关的预算项目。如果 Authenticator 存在于浏览器和 Client 中，Endpoint 安全就直接属于认证模型。

用户现在应该做什么

没有充分理由为了预防而删除全部通行密钥，再回到更弱的密码。

合理的做法是：

• 及时更新 Chrome 与 Windows；
• 只安装可信软件与 Browser Extension；
• 保持设备保护、Windows Hello 与恶意软件防护处于启用状态；
• 不要确认意外出现的通行密钥或 Windows Hello 对话框；
• 不要随意确认意外的 Recovery-PIN 或 Re-Onboarding 请求；
• 检查 Google Password Manager 与重要服务中的已注册设备和通行密钥；
• 为特别重要的账号考虑使用单独的 Hardware Security Key；
• 不要继续使用可疑 Endpoint，应将其隔离并接受调查。

如果有恶意软件、Chrome 状态被篡改或内存转储的具体迹象，应假定 Credential 与 Session 可能已被窃取。此时只更改密码是不够的。必须重建 Endpoint 或可靠地清理它、吊销活动 Session、检查 Recovery 方式、删除未知通行密钥，并重新注册可信 Authenticator。

对于可能的 Golden Pass-ta-key 事件，必须格外谨慎。已发布的研究没有说明用户可以怎样简单地轮换 SDS。这意味着，不要声称更改 PIN 或仅重新创建一把通行密钥就一定能解决问题。对于高价值账号，我建议在清理 Endpoint 后注册新的设备绑定 Credential，删除旧的同步 Credential，并让 Provider 或 Incident Response 团队参与恢复。

真正的教训

通行密钥不是抵御一切入侵的盾牌。它解决的是一个具体且非常重大的问题：人们不再需要把可重复使用的秘密交给服务器，或一个可能伪造的网站。

Pass-ta-key 揭示了下一层问题。一旦私钥可以便利地在设备间同步，就会形成密钥加密、设备信任与 Recovery 基础设施。即便底层 WebAuthn 协议是正确的，这套基础设施也可能包含缺陷。

错误的反应是宣布通行密钥已经失败。同样错误的是，把本地恶意软件感染后发生的一切攻击都视为无足轻重。

因此，我的判断依然清晰：继续部署通行密钥，但要准确描述它的安全承诺。同步通行密钥非常擅长抵御钓鱼。设备绑定 Hardware Key 为高价值账号提供了更强的边界。任何 Authenticator 都不能取代干净的 Endpoint、受到控制的 Recovery 流程以及正确实现的服务器端检查。

通行密钥已经把防范钓鱼的大门锁得更牢。Pass-ta-key 则提醒我们，对于已经站在屋内的攻击者，需要另一道防线。

下次再见。
Joe

常见问题