【要約】Device-bound session credentials land in Chrome. Here's how they stop account takeovers. [Ars_Technica] | Summary by TechDistill
> Source: Ars_Technica
Execute Primary Source
// Problem
攻撃者は、2FAやPasskeysの普及に伴い、従来のパスワード攻撃が困難になった。その結果、認証済みのセッションを盗む手法へシフトしている。
- ・Infostealerマルウェアによるセッションクッキーの窃取。
- ・AiTM（Adversary-in-the-Middle）攻撃によるクッキーの奪取。
- ・盗んだクッキーを自身のブラウザへ貼り付けることによる不正アクセス。
// Approach
Googleは、デバイス内のセキュアなハードウェア領域を利用して、クッキーの有効性を検証する仕組みを導入した。
- ・TPM（Windows）やSecure Enclave（macOS/iOS）に固有の秘密鍵を保存。
- ・サーバー側でユーザーの公開鍵を管理。
- ・サーバーが送る認証チャレンジに対し、デバイス内の秘密鍵で署名を行う。
- ・署名（Authentication Assertion）がないクッキーはサーバーが拒否。
// Result
この技術により、攻撃者がクッキーを盗んでも、デバイス固有の署名ができないため不正アクセスを阻止できる。
- ・Windows版Chrome 147およびmacOS版Chrome 150で限定テストを開始。
- ・Passkeysと同様の、共有秘密に依存しない強力な認証モデルを実現。
- ・Chromium系ブラウザへの展開が期待される。
Senior Engineer Insight
> セッション管理が「共有秘密」から「デバイスバインド」へ移行する。セキュリティ強度は劇的に向上するが、サーバー側の実装負荷は無視できない。公開鍵の管理と、チャレンジ/レスポンス方式のプロトコル実装が必要となる。また、ハードウェア依存により、非対応環境での挙動管理が運用上の課題となるだろう。