Google hat mit der allgemeinen Bereitstellung der Technologie Device Bound Session Credentials (DBSC) für Windows-Nutzer im Browser Chrome 146 begonnen, nachdem sie erstmals im April 2024 angekündigt worden war. In einer kommenden Chrome-Version soll sie auf macOS ausgeweitet werden. Die Technologie zielt auf eines der häufigsten Sicherheitsprobleme bei Sitzungen: den Diebstahl von Cookies, der Angreifern den Zugriff auf Konten ermöglicht, ohne dass sie Passwörter benötigen.
Der Diebstahl von Sitzungen erfolgt üblicherweise, wenn ein Nutzer unbeabsichtigt Schadsoftware herunterlädt. Nach ihrer Ausführung kann die Schadsoftware vorhandene Cookies aus dem Browser extrahieren oder abwarten, bis sich der Nutzer bei neuen Konten anmeldet, und diese Token anschließend an einen vom Angreifer kontrollierten Server senden. Google weist darauf hin, dass Informationsdiebstahl-Familien wie LummaC2 bei der Erfassung von Zugangsdaten immer ausgefeilter werden.
Die Gefahr dieser Dateien nimmt durch die längere Gültigkeitsdauer mancher Cookies zu; Angreifer können sie für unbefugten Zugriff auf Konten verwenden und sie anschließend unter kriminellen Akteuren sammeln, weitergeben oder verkaufen. Fortschrittliche Schadsoftware kann nach dem Zugriff auf ein Gerät außerdem Dateien und den Speicher auslesen, in denen Browser Authentifizierungs-Cookies speichern. Daher ist Google der Ansicht, dass sich das Extrahieren von Cookies unabhängig vom Betriebssystem nicht zuverlässig allein durch Software verhindern lässt.
Bindung der Sitzung an einen Schlüssel, der das Gerät nicht verlässt
DBSC ändert dieses Modell, indem die Authentifizierungssitzung kryptografisch an ein bestimmtes Gerät gebunden wird. Die Technologie verwendet hardwaregestützte Sicherheitsmodule wie das Trusted Platform Module (TPM) unter Windows und die Secure Enclave unter macOS, um ein einzigartiges Paar aus öffentlichem und privatem Schlüssel zu erzeugen. Der private Schlüssel kann nicht vom Gerät exportiert werden.
Der Server stellt erst dann neue, kurzlebige Cookies aus, wenn Chrome nachgewiesen hat, dass es den mit der Sitzung verbundenen privaten Schlüssel besitzt. Da der Angreifer diesen Schlüssel nicht stehlen kann, laufen extrahierte Cookies schnell ab und werden für den Kontozugriff unbrauchbar. Google zufolge wurde seit der Einführung einer frühen Version des Protokolls im vergangenen Jahr ein deutlicher Rückgang beim Diebstahl von durch DBSC geschützten Sitzungen beobachtet.
Websites jeder Größe können hardwaregebundene Sitzungen übernehmen, indem sie ihren Backend-Systemen eigene Endpunkte für Registrierung und Aktualisierung hinzufügen und dabei die bestehende Frontend-Kompatibilität beibehalten. Der Browser übernimmt die komplexen Verschlüsselungsvorgänge und die Rotation der Cookies im Hintergrund, während die Webanwendung weiterhin Standard-Cookies für den Zugriff auf ihre Dienste verwendet.
Schutz von Sitzungen ohne Nutzerverfolgung
DBSC wurde unter Berücksichtigung des Datenschutzes entwickelt. Jede Sitzung basiert auf einem eigenen Schlüssel, wodurch Websites daran gehindert werden, diese Anmeldedaten zu verwenden, um die Aktivitäten eines Nutzers zwischen verschiedenen Sitzungen oder zwischen mehreren Websites auf demselben Gerät zu verknüpfen. Das Protokoll sendet außerdem keine Gerätekennungen oder Authentifizierungsdaten an den Server, mit Ausnahme des öffentlichen Sitzungsschlüssels, der zum Nachweis des Besitzes des privaten Schlüssels erforderlich ist.
Google zufolge verringert dieser Informationsaustausch die Risiken, dass die Technologie zur websiteübergreifenden Verfolgung oder zur Erstellung eines Geräte-Fingerabdrucks verwendet wird.
Offener Standard und laufende Weiterentwicklung
DBSC wurde von Anfang an als offener Webstandard über den W3C-Prozess und mit Unterstützung der Web Application Security Working Group entwickelt. Google arbeitete bei der Gestaltung des Standards mit Microsoft zusammen. Außerdem beteiligten sich zahlreiche Webplattformen, darunter Okta, im vergangenen Jahr an zwei Origin Trials und lieferten auf Grundlage von Tests und Nutzung Rückmeldungen.
Google stellt Entwicklern einen Implementierungsleitfaden sowie die Protokollspezifikationen, ein GitHub-Repository und eine Seite zum Melden von Fehlern oder Vorschlagen von Funktionen zur Verfügung.
Zu den künftigen Entwicklungsbereichen gehören:
- Absicherung der föderierten Identität: Erweiterung von DBSC zur Unterstützung der Verknüpfung verschiedener Ressourcen, sodass die Sitzung der vertrauenden Partei während des gesamten Single-Sign-on-Vorgangs an den ursprünglichen Geräteschlüssel des Identitätsanbieters gebunden bleibt.
- Erweiterte Registrierungsfunktionen: Bindung von Sitzungen an bereits vorhandenes vertrauenswürdiges Schlüsselmaterial wie mTLS-Zertifikate oder Hardware-Sicherheitsschlüssel, anstatt bei der Anmeldung einen neuen Schlüssel zu erzeugen.
- Breitere Geräteunterstützung: Prüfung der Ergänzung softwarebasierter Schlüssel zum Schutz von Geräten, die keine dedizierte Sicherheits-Hardware enthalten.