Chrome DBSC 上线：用硬件绑定让被盗 Cookie 变废纸

信息窃取恶意软件（Infostealer）正在成为网络安全领域最棘手的威胁之一。攻击者通过 LummaC2、Vidar、StealC、AMOS 等恶意软件家族，窃取浏览器中的会话 Cookie，从而绕过多因素认证（MFA），直接接管用户账户。因为 Cookie 是在身份验证之后生成的，即使启用了 MFA，被盗的 Cookie 仍然可以让攻击者畅通无阻。

谷歌在 Chrome 146（Windows 版）中正式推出了 设备绑定会话凭据（Device Bound Session Credentials，DBSC）功能，试图从根本上解决这个问题。

核心机制：把登录态锁死在物理设备上

DBSC 的工作原理可以概括为三个关键步骤：

1. 密钥绑定：利用硬件级安全模块（Windows 上的 TPM、macOS 上的 Secure Enclave），生成一对公钥/私钥。私钥存储在硬件安全模块中，无法被导出。
2. 会话注册：当用户登录时，浏览器向服务器注册会话，同时将公钥发送给服务器。
3. Cookie 轮换：服务器发放短时效的会话 Cookie。Cookie 的续期依赖于浏览器证明它持有对应的私钥。由于私钥无法被窃取，即使 Cookie 被盗，也会在短时间内过期失效。

这种设计的核心优势在于：它不试图阻止恶意软件读取 Cookie（这在软件层面几乎不可能实现），而是让被盗的 Cookie 变得毫无价值——攻击者拿到的是一个即将过期的凭据，却没有能力续期。

从"事后检测"到"事前预防"

传统的会话劫持防护依赖于事后检测：通过分析异常登录行为、IP 地址变化等启发式规则来识别被盗凭据。这是一种被动防御，持续性的攻击者往往能找到绕过方法。

DBSC 改变了这个范式。它不依赖行为分析或威胁检测，而是通过密码学手段在协议层面确保：只有持有硬件私钥的设备才能维持会话。这是一个结构性的安全改进。

谷歌表示，DBSC 早期版本在过去一年中已经部署，对于受 DBSC 保护的会话，观察到了"显著的会话盗窃减少"。

隐私设计：不引入新的追踪手段

DBSC 在安全性上的一个值得注意的设计是：每个会话使用独立的密钥，网站无法利用这些凭据来关联用户在不同会话或不同网站上的活动。协议不会泄露设备标识符或远程证明数据，仅传输用于证明密钥持有权的每会话公钥。这意味着 DBSC 在增强安全性的同时，不会成为跨站追踪或设备指纹识别的工具。

开放标准：W3C 标准化进程

DBSC 从一开始就被设计为开放 Web 标准，通过 W3C 的 Web 应用安全工作组推进标准化。谷歌与微软合作设计该标准，确保其在 Web 生态中的适用性。过去一年中，谷歌进行了两次 Origin Trial，包括 Okta 在内的多个平台参与了测试并提供了反馈。

对于 Web 开发者，谷歌提供了开发者指南，标准规范和代码仓库均已在 GitHub 上公开（W3C 规范、GitHub 仓库）。

未来路线图

DBSC 的后续发展将聚焦三个方向：

• 联合身份保护：扩展协议以支持跨源绑定，确保在 SSO（单点登录）流程中，依赖方的会话始终绑定到与身份提供方相同的设备密钥，在联合登录全过程中维持设备绑定的信任链。
• 高级注册能力：允许将 DBSC 会话绑定到预先存在的可信密钥材料（如 mTLS 证书或硬件安全密钥），而非在登录时生成新密钥，为企业环境提供更强的安全保障。
• 更广泛的设备支持：探索在缺乏硬件安全模块的设备上通过软件密钥提供保护。

macOS 版本的 DBSC 支持将在后续 Chrome 版本中推出。

DBSC 代表了 Web 认证安全的一个重要演进方向。在信息窃取恶意软件日益猖獗的背景下，通过硬件绑定将 Cookie 的价值降至零，是一个简洁而有效的工程思路。对于网站运营者和开发者来说，现在就可以开始评估集成 DBSC 的可行性——毕竟，在安全领域，从被动响应转向主动防护，永远是正确的方向。