Google 开始面向 Windows 用户公开提供 Chrome 146 浏览器上的设备绑定会话凭据（Device Bound Session Credentials，DBSC）技术。该技术最初于 2024 年 4 月公布，并计划在未来的 Chrome 版本中扩展到 macOS。该技术旨在解决最常见的会话安全问题之一：Cookie 被盗后，攻击者无需密码即可访问账户。
会话盗窃通常发生在用户无意中下载恶意软件时。恶意软件运行后，可以从浏览器中提取现有 Cookie，或等待用户登录新账户，然后将这些令牌发送到攻击者控制的服务器。Google 指出，LummaC2 等信息窃取恶意软件家族在收集凭据方面变得更加先进。
这类 Cookie 的风险因部分 Cookie 的有效期较长而进一步增加；攻击者可以利用它们未经授权访问账户，然后在犯罪团伙之间收集、交换或出售这些 Cookie。此外，高级恶意软件在获得设备访问权限后，还能够读取浏览器存储身份验证 Cookie 的文件和内存。因此，Google 认为，无论使用何种操作系统，仅依靠软件都不存在可靠的方式来阻止 Cookie 被提取。
将会话绑定到不会离开设备的密钥
DBSC 通过在加密层面将身份验证会话绑定到特定设备，改变了这一模式。该技术使用硬件支持的安全模块，例如 Windows 中的可信平台模块（TPM）和 macOS 中的安全隔区（Secure Enclave），生成一对唯一的公钥和私钥。私钥无法从设备中导出。
只有在 Chrome 证明其拥有与会话关联的私钥后，服务器才会发放新的短期 Cookie。由于攻击者无法窃取该密钥，任何被提取的 Cookie 都会很快失效，无法继续用于访问账户。Google 表示，自去年推出该协议的早期版本以来，其观察到受 DBSC 保护的会话盗窃事件大幅减少。
大小网站都可以通过在后端系统中添加用于注册和更新的专用端点，采用硬件绑定会话，同时保持现有前端的兼容性。浏览器会在后台处理复杂的加密操作并轮换 Cookie，而 Web 应用则继续使用标准 Cookie 访问其服务。
在不跟踪用户的情况下保护会话
DBSC 的设计考虑了隐私保护。每个会话都基于独立密钥，因此网站无法利用这些凭据将用户在不同会话之间，或在同一设备上的多个网站之间的活动关联起来。除证明持有私钥所必需的会话专用公钥外，该协议不会向服务器发送设备标识符或认证数据。
Google 表示，这种信息交换限制了利用该技术进行跨网站跟踪或构建设备识别指纹的风险。
开放标准与持续开发
DBSC 从一开始就被设计为一种开放 Web 标准，通过 W3C 流程并获得 Web 应用安全工作组的认可。Google 与 Microsoft 合作设计了该标准；包括 Okta 在内的多个 Web 平台也参与了去年的两次 Origin Trials，并根据测试和使用情况提供了反馈。
Google 为开发者提供了实施指南，以及协议规范、GitHub 仓库和用于报告错误或提出功能建议的页面。
未来的开发领域包括：
- 保护单点登录：扩展 DBSC 以支持不同资源之间的绑定，使依赖方会话在整个单点登录过程中始终与身份提供商处使用的原始设备密钥保持关联。
- 高级注册能力：将会话绑定到预先存在的可信密钥材料，例如 mTLS 证书或硬件安全密钥，而不是在登录时创建新密钥。
- 更广泛的设备支持：研究添加基于软件的密钥，以保护不包含专用安全硬件的设备。