Session-Diebstahl tritt laut Google typischerweise dann auf, wenn Nutzer unbemerkt sogenannte Infostealer-Malware auf ihre Systeme herunterladen. Von diesen Schädlingen gibt es zahlreiche Familien — Google nennt unter anderem Atomic, Lumma und Vidar Stealer —, die ein breites Spektrum an Daten von kompromittierten Systemen abgreifen können, darunter auch Cookies.

Weil Sitzungscookies häufig eine lange Lebensdauer haben, lassen sich damit fremde Online-Konten übernehmen, ohne dass das Passwort bekannt sein muss. Einmal gesammelt, werden die Tokens gebündelt und an andere Akteure verkauft, die darauf eigene Angriffe aufbauen.

DBSC setzt an diesem Punkt an, indem es die Authentifizierungssitzung kryptografisch an ein bestimmtes Gerät koppelt. Laut Google kommen dabei hardwaregestützte Sicherheitsmodule zum Einsatz — das Trusted Platform Module (TPM) unter Windows und die Secure Enclave unter macOS. Diese erzeugen ein eindeutiges Schlüsselpaar aus öffentlichem und privatem Schlüssel, das sich nicht vom Gerät exportieren lässt.

Neue, kurzlebige Sitzungscookies werden nur dann ausgegeben, wenn Chrome dem Server den Besitz des passenden privaten Schlüssels nachweist. Da Angreifer diesen Schlüssel nicht stehlen können, verfallen abgezogene Cookies rasch und sind für sie wertlos. Unterstützt ein Gerät keine sichere Schlüsselspeicherung, fällt DBSC laut Googles Entwicklerdokumentation auf das Standardverhalten zurück, ohne den Anmeldevorgang zu unterbrechen.

Seit dem Start habe man einen deutlichen Rückgang beim Session-Diebstahl beobachtet, erklärt das Unternehmen — ein frühes Anzeichen für die Wirksamkeit der Gegenmaßnahme. Der offizielle Start sei erst der Anfang: Google will DBSC auf weitere Gerätetypen ausweiten und zusätzliche Funktionen für die Einbindung in Unternehmensumgebungen einführen.

Den Standard hat Google gemeinsam mit Microsoft entworfen, mit dem Ziel, ihn als offenen Web-Standard zu etablieren. Das Unternehmen betont zudem, dass die DBSC-Architektur von Grund auf auf Datenschutz ausgelegt sei. Durch den Ansatz separater Schlüssel könnten Websites die Sitzungs-Anmeldedaten nicht nutzen, um die Aktivitäten eines Nutzers über verschiedene Sitzungen oder Seiten auf demselben Gerät hinweg zu verknüpfen.

Das Protokoll sei zudem schlank konzipiert: Es gebe über den pro Sitzung erforderlichen öffentlichen Schlüssel hinaus keine Geräte­kennungen oder Attestierungsdaten an den Server preis. Dieser minimale Informationsaustausch stelle sicher, dass DBSC Sitzungen absichert, ohne seitenübergreifendes Tracking zu ermöglichen oder als Mechanismus zum Fingerprinting von Geräten zu dienen.