在双因素认证、通行密钥等更强验证方式普及之后，单纯靠偷密码已经很难得手，攻击者于是把目标转向了「会话 Cookie」。网站为了省去每次刷新都重新验证的麻烦，会把一段代表「已登录」的字符串存在浏览器里，这就是会话 Cookie。一旦这段 Cookie 被窃走，攻击者把它粘贴进自己的浏览器，就能在有效期内顶替原主人的身份。

把私钥焊死在芯片里

DBSC 的思路，是将会话凭证的加密密钥存放在设备内置的一处「硬件堡垒」中。在 Windows 上，这处堡垒叫 TPM（可信平台模块）；在 macOS 与 iOS 上，它叫安全隔区（Secure Enclave）；其他平台也有各自的名称。近期发布的 Windows 版 Chrome 147 与 macOS 版 Chrome 150，已经能够在这类芯片里生成并保存密钥。

它的工作逻辑和通行密钥相似：网站服务端只保存用户的公钥，并在下发会话 Cookie 时附带一个验证挑战；浏览器必须用存放在 TPM 或安全隔区里的私钥对挑战签名，服务端才会认可。由于硬件会把私钥隔离起来、拒绝将其导出，攻击者即便偷走了 Cookie，也无法用私钥完成签名应答，自然无法冒用身份。

安全研究者、Report URI 创始人 Scott Helme 在个人博客中评价说：「攻击者无法从设备里偷走私钥，这正是核心保护所在。他能偷走 Cookie，却无法用仍安全地留在你设备上的私钥去应答 DBSC 挑战。」

目前仍是灰度测试

需要留意的是，DBSC 眼下并非全面开放。它仅出现在 Windows 版 Chrome 147 与 macOS 版 Chrome 150 中，而且只对一部分用户开启，外界判断谷歌仍在小范围灰度测试。用户若想确认自己的浏览器是否已启用，可以打开开发者工具，切到「应用」标签向下滚动——当登录到支持 DBSC 的网站时，若保护已开启，就会看到「设备绑定会话」的字样。

至于其他基于 Chromium 内核的浏览器是否会跟进，目前尚不清楚，但业界普遍预期只是时间问题。Chrome 安全团队提醒，会话 Cookie 窃取类攻击（包括信息窃取木马与中间人攻击）近年来明显上升，DBSC 是继通行密钥之后，又一层「不依赖共享密钥」的身份验证思路，目的都是让攻击者更难把用户的登录身份整个搬走。

来源：Ars Technica（作者 Dan Goodin，2026 年 8 月 11 日）