Chrome把登录凭证焊死在电脑上，黑客偷了cookie也白搭

去年全球因会话cookie被盗导致的账户劫持事件增长了340%，而企业平均发现这类入侵需要287天。Google这次更新的Chrome 146，直接给登录凭证上了把物理锁——偷数据的人拿到cookie也没用，因为钥匙根本带不走。

DBSC：把"钥匙"焊死在主板上

这项叫Device Bound Session Credentials（设备绑定会话凭证，DBSC）的技术，核心逻辑简单粗暴：用Windows的TPM（可信平台模块）或同等硬件安全芯片，生成一对公私钥。私钥永远不出芯片，cookie的续命全靠它签名认证。

Google安全团队的解释很直白：「攻击者无法窃取这个密钥，任何被窃取的cookie都会迅速过期，对攻击者毫无用处。」网站只需在后端加两个端点——注册和刷新——前端完全不用改，Chrome自动处理加密和轮换。

这相当于把传统的"密码+短信验证码"模式，变成了"密码+短信+这台电脑缺一不可"。黑客以前偷cookie等于复制了房卡，现在房卡里有颗芯片，拿到隔壁小区刷不开门。

为什么cookie成了新黄金

多因素认证（MFA）普及后，直接撞密码的难度飙升。但MFA验证通过后生成的会话cookie，成了绕过所有防御的"后门钥匙"。

信息窃取木马（infostealer）的产业链因此爆发。这类恶意软件专门扒浏览器里的cookie、自动填充的密码、甚至加密货币钱包。2024年，RedLine、Raccoon、Lumma等主流信息窃取工具的地下交易量同比增长了217%，单条高质量cookie在暗市售价从几美元涨到数百美元。

企业场景更致命。员工用公司设备登录SaaS平台，cookie被盗等于企业网络边界被撕开。微软2024年威胁情报报告显示，超过80%的账户接管攻击始于被盗会话cookie，而非密码泄露。

Google的DBSC早期版本2025年就已小范围测试。官方数据称，受保护会话的盗窃率出现「显著下降」——虽然没给具体数字，但Chrome安全团队罕见地用了"显著"这个词，说明效果超出内部预期。

Windows先上，Mac排队

目前DBSC只在Chrome 146 Windows版启用，macOS版本"未来几周"推送。Linux和ChromeOS的时间表未公布。

这个优先级很现实：Windows是企业信息窃取攻击的重灾区。HP Wolf Security 2024年报告显示，91%的企业恶意软件感染发生在Windows终端。macOS虽然份额上升，但攻击者目前仍优先瞄准Windows的庞大基数。

技术实现上，DBSC依赖操作系统级的硬件安全模块。Windows 10/11的TPM 2.0已成标配，苹果T2/Secure Enclave的API对接需要额外适配工作。Google选择先解决最大痛点，再逐步覆盖。

网站适配：轻量改造，收益明确

对网站运营者，接入DBSC的成本可控。Google提供了完整的协议规范，核心就两步：注册端点生成设备绑定凭证，刷新端点用私钥签名续期。现有cookie逻辑完全保留，只是多了层硬件验证。

已确认接入的平台包括Google自家服务（Gmail、Workspace等），以及部分金融和SaaS企业。银行类应用对这类技术最积极——会话劫持导致的欺诈赔付，成本远高于改造投入。

但大规模普及需要时间。中小站点的安全预算和人力有限，除非Chrome强制要求或提供一键接入方案，否则观望情绪会占主导。Google目前的策略是"先示范，后推广"，用头部案例带动生态。

攻击者的下一步

DBSC不是银弹。它堵死了"偷cookie异地使用"这条路，但信息窃取木马不会消失，只会转型。

可能的绕过方向：一是转向实时会话劫持——在受害者设备上直接操作，而非窃取凭证后离线使用。这要求攻击者维持对设备的持续控制，风险和成本都更高。二是针对DBSC注册流程的攻击，在设备首次绑定时植入恶意逻辑。三是物理层攻击，比如针对TPM的侧信道分析，但这需要接近国家级的能力。

更现实的威胁是"降级攻击"：强迫网站回退到传统cookie模式。这需要同时控制受害者的网络流量，难度不小，但针对特定高价值目标的定向攻击中并非不可能。

信息窃取木马作者已经在讨论DBSC的应对。某俄语地下论坛的帖子显示，有开发者尝试用API hooking技术拦截Chrome与TPM的通信，但尚未有成熟方案流出。这场攻防战的下一回合，可能发生在操作系统内核层面。

浏览器安全的新战场

Chrome不是唯一行动者。微软Edge正在测试类似功能，基于Windows Hello的密钥绑定。苹果的Safari则把筹码押在Passkey上，试图跳过cookie altogether。Mozilla Firefox的进度相对滞后，其硬件安全模块的支持仍在规划中。

这场竞赛的本质，是把身份验证的锚点从"用户知道什么/拥有什么"，进一步延伸到"用户正在使用什么设备"。好处是攻击成本指数级上升；代价是用户换设备或重装系统时的摩擦增加，企业IT支持工单可能暴涨。

Google的选择很产品经理：先解决企业最痛的会话劫持，用户体验的优化后续迭代。DBSC的密钥备份和跨设备同步功能已在路线图，但优先级低于先堵住最大的漏洞。

Chrome 146的更新日志里，DBSC被埋在"安全修复"分类下，没有大张旗鼓。这种低调很符合Google的风格——真正影响数亿用户的改动，往往不需要发布会。

你的企业SaaS平台接入DBSC了吗？如果还没，安全团队或许该给Chrome企业版的管理后台多刷几遍更新状态。