Chrome最近给浏览器里的登录状态上了一把新锁。这把锁不锁密码,锁的是会话Cookie——你登录网站后,浏览器帮你记住"已经验证过"的那串字符。锁的钥匙不放在浏览器里,而是焊进设备的硬件保险箱:Windows上是TPM,Mac上是Secure Enclave。Ars Technica在8月11日的报道里,把这套机制形容成"迄今可能最好的"账户劫持防护。这个说法值得琢磨一下——因为它从提出原型到现在,已经过去两年,而眼下依然只是小范围试点。
密码防住了,Cookie却成了新漏洞
这几年密码本身越来越难偷。2FA、Passkey普及之后,光靠一个密码已经登不进账户,传统钓鱼失效了。
攻击者的应对很直接:不偷密码,偷登录之后的状态。信息窃取型恶意软件(infostealer)和"中间人"式攻击,专门从受害者浏览器里捞会话Cookie,再原样粘到自己的浏览器上——网站认的是Cookie,不是人,于是攻击者直接冒充成"已登录的你"。这类Cookie在地下市场里已经是标准商品,批量打包、批量售卖。
DBSC怎么挡:钥匙不给,拿了也没用
设备绑定会话凭证(DBSC)的思路是:给每个会话生成一对密钥,私钥永远锁在TPM或Secure Enclave里,不可导出。网站只存公钥,之后每隔一段时间发一次挑战,浏览器必须用私钥签名回应,才能续期这个短命的Cookie。
Cookie被偷了不要紧,私钥偷不走——TPM不会把它交出来。攻击者把偷来的Cookie粘到自己电脑上,网站发挑战,他签不出正确的答案,连接就断了。研究者Scott Helme的说法很直白:攻击者能偷Cookie,但答不出DBSC的题。
从原型到"采用",走了两年,范围还很小
DBSC不是今年新想法。Chromium团队早在2024年4月就在官方博客里提出了原型,当时明确说是面向部分Google账户用户、在Chrome Beta里的小范围测试。
两年后,也就是这次Ars报道的节点,DBSC支持的是Chrome 147(Windows)和150(macOS),而且依然"只对限定用户开放"。这意味着"Chrome adopts"这个说法,更准确的翻译是"扩大试点",而不是"全量上线"。想确认自己有没有中签,可以在开发者工具的Application面板里找"device bound sessions"这一项。
挡得住一种偷法,挡不住另外四种
WICG(负责这项Web标准的工作组)自己写得很清楚:DBSC不是万能锁,它压缩的是"离线偷Cookie、异地重放"这一个具体窗口。
- 结论.只要攻击者手里没有你设备上的持续控制权,偷来的Cookie就是废纸一张。
- 风险.攻击者若能在你设备上长期驻留、或者干脆钓鱼诱你新建一次登录,DBSC等于没有设防。
持续驻留的恶意软件、XSS/CSRF、钓鱼新建会话、服务器端Cookie泄露——这四类攻击DBSC统统挡不住,因为问题根本不在Cookie能不能被签名,而在攻击者是否已经站在了你的设备里。
DBSC和Passkey常被读者混为一谈,其实两者管的是不同环节:Passkey证明"登录时是谁",DBSC保护的是"登录之后的状态能不能被搬走"。缺了任何一环,另一环都补不上这个洞。
更早的一版思路——Token Binding协议,也是想把会话绑到设备密钥上,结果因为跨浏览器支持凑不齐而不了了之。这段前车之鉴,Chromium团队应该记得。
为什么故意不做"硬件认证",这是权衡不是疏漏
DBSC刻意没有加入远程硬件认证(attestation)——也就是让服务器验证"这把密钥真的躺在一台真实TPM里"。
这不是技术做不到,是不想做。一旦加上认证,服务器就能顺带识别出你用的是哪块芯片、哪台设备,这跟设备指纹追踪没什么本质区别,还会把没有TPM的老机器、Linux、虚拟机用户直接排除在保护之外。于是设计者选择留一个信任上限:服务器只能确认"同一把密钥一直在续期",确认不了它到底焊在哪。
社区讨论里还提到一种新麻烦——攻击者未必需要冒充你,只要删掉或破坏你本地的DBSC状态,就能逼你重新登录一次,顺手制造干扰。
这套机制目前只在Chrome(以及理论上未来的Edge)身上跑,Firefox和Safari都还没有对等能力。黑产不是傻子,一个平台设防,他们会往没设防的平台挪。DBSC能不能真正压缩账户劫持的规模,取决于其他浏览器什么时候跟上,以及有多少网站愿意为这套短命Cookie的续期逻辑改造自己的登录系统。
锁是真锁,门却没关严。
Google这次做的是一件对的事,方向没错,机制也扎实——但"迄今最佳防护"这句话,更像是说给标题看的。对普通用户,真正值得记住的是:这把锁只防一种小偷,另外几种,还得靠别的门锁。