Google Chrome rollt Schutz gegen Diebstahl von Session-Cookies für alle Nutzer aus

Die neue Funktion Device Bound Session Credentials bindet Sitzungs-Cookies kryptografisch an den Sicherheitschip des Computers und verhindert Kontenübernahmen.

Der Technologiekonzern Google hat die allgemeine Verfügbarkeit einer neuen Sicherheitsarchitektur für seinen Webbrowser Chrome bekannt gegeben. Die Funktion mit der Bezeichnung Device Bound Session Credentials, abgekürzt DBSC, wird schrittweise für alle Anwenderklassen ausgerollt. Der offizielle Start des weltweiten Rollouts begann am 25. Mai 2026 und soll innerhalb von maximal 60 Tagen vollständig abgeschlossen sein. Die Technologie wurde erstmals im Jahr 2024 konzipiert und befand sich seit Frühjahr 2026 in einer intensiven Beta-Testphase auf Systemen mit dem Betriebssystem Windows.

Mit dem Übergang in den Status der allgemeinen Verfügbarkeit dehnt Google den Schutz auf alle Google-Workspace-Kunden, Workspace-Individual-Abonnenten sowie auf Inhaber privater Google-Konten aus. Ziel der Maßnahme ist es, das weitverbreitete Ausnutzen gestohlener Sitzungsdaten durch Cyberkriminelle proaktiv zu unterbinden und die missbräuchliche Übernahme von Benutzerkonten auf Hardware-Ebene zu blockieren.

Kryptografische Verknüpfung von Sitzungsdaten mit dem Sicherheitschip

Die technische Funktionsweise von DBSC basiert auf einer strikten Verknüpfung digitaler Identifikationsmerkmale mit der physischen Hardware des Endgeräts. Wenn sich ein Anwender bei einem kompatiblen Webdienst anmeldet, generiert der Browser nicht mehr nur ein klassisches Sitzungs-Cookie, sondern initiiert über ein spezielles HTTP-Protokoll die Erstellung eines asymmetrischen kryptografischen Schlüsselpaares. Diese Schlüssel werden direkt innerhalb des hardwarebasierten Sicherheitsmoduls des Computers erzeugt und dort isoliert gespeichert. Auf Computern mit dem Betriebssystem Windows nutzt Chrome hierfür das Trusted Platform Module, kurz TPM. Für Geräte unter macOS ist die Integration des Secure Enclave vorgesehen.

Da der private Schlüssel das Hardware-Modul physisch niemals verlässt, kann er selbst bei einer vollständigen Kompromittierung des Betriebssystems nicht extrahiert oder kopiert werden. Der Webserver fordert den Browser in regelmäßigen Abständen dazu auf, den Besitz dieses privaten Schlüssels kryptografisch nachzuweisen, bevor neue, kurzlebige Sitzungs-Cookies ausgestellt werden. Kann der Browser diesen hardwaregebundenen Nachweis nicht erbringen, weil das Cookie auf ein fremdes Gerät kopiert wurde, wird der Zugriff verweigert und die Sitzung sofort ungültig.

Effektive Blockierung von Infostealer-Malware wie Lumma und Rhadamanthys

Mit dieser Umstellung reagiert der Softwarehersteller auf die rasant gestiegene Bedrohung durch spezialisierte Schadsoftware, die sogenannten Infostealer. Schadsoftware-Familien wie LummaC2 oder Rhadamanthys haben sich darauf spezialisiert, die lokalen Cookie-Datenbanken von Browsern systematisch auszulesen. Da diese Dateien den erfolgreichen Login inklusive einer bereits absolvierten Zwei-Faktor-Authentisierung bestätigen, konnten Angreifer die entwendeten Cookies bisher einfach auf ihren eigenen Geräten einspielen, um vollen Zugriff auf die Konten der Opfer zu erhalten, ohne Passwörter oder Verifizierungscodes eingeben zu müssen.

Zudem missbrauchten kriminelle Netzwerke in der Vergangenheit gezielt undokumentierte Schnittstellen, wie den Google-OAuth-MultiLogin-Endpunkt, um abgelaufene Authentifizierungs-Cookies im Hintergrund betrügerisch zu erneuern und dauerhaften Zugriff zu behalten. Durch den Einsatz von DBSC wird dieser Angriffsvektor vollständig geschlossen. Da den Angreifern auf ihren externen Systemen der physische Zugriff auf das TPM des Originalgeräts fehlt, verfallen gestohlene Cookies innerhalb kürzester Zeit und sind für Kriminelle wertlos.

Automatische Aktivierung im Enterprise-Umfeld und funktionale Grenzen

Für die Administration von IT-Infrastrukturen in Unternehmen bringt die allgemeine Verfügbarkeit prozessuale Veränderungen mit sich. Google hat festgelegt, dass DBSC für alle Google-Workspace-Kunden standardmäßig aktiviert wird. Es existiert keine administrative Option innerhalb der Google Admin Konsole, um diese Sicherheitsfunktion zu deaktivieren oder zu unterdrücken. IT-Verantwortliche können die erfolgreichen Bindungs- und Validierungsereignisse über das integrierte Sicherheits-Untersuchungswerkzeug in den Audit-Protokollen der User Log Events überwachen.

Trotz der gesteigerten Sicherheit verweisen Bedrohungsanalysten auf funktionale Einschränkungen der aktuellen Implementierung. DBSC operiert als Client-Server-Protokoll, was bedeutet, dass die Technologie nur dann wirksam schützt, wenn auch die serverseitige Plattform oder der SaaS-Anbieter die entsprechenden Registrierungs- und Aktualisierungs-Endpunkte implementiert hat. Während Google und Identitätsdienste wie Okta diese Unterstützung bereits bieten, fehlt sie bei vielen internen Unternehmensanwendungen und spezialisierten Cloud-Tools noch vollständig. Zudem schützt die Funktion keine Passwörter, VPN-Konfigurationen oder SSH-Schlüssel, die von Infostealern ebenfalls in großem Stil erbeutet werden. Geräte ohne kompatibles TPM-Modul fallen zudem automatisch auf das standardmäßige, ungesicherte Cookie-Verfahren zurück. Um eine bretere Abdeckung zu erreichen, treibt Google die Spezifikation als offenen Webstandard über das World Wide Web Consortium, kurz W3C, voran, um eine künftige Integration in alternative Browser zu ermöglichen.

Relevanz für die IT-Governance und das strategische IT-Risikomanagement

Die flächendeckende Einführung hardwaregebundener Sitzungen hat tiefgreifende Auswirkungen auf die übergeordnete IT-Governance und das strategische IT-Risikomanagement in modernen Organisationen im Jahr 2026. Da der Diebstahl von Identitäten über kompromittierte Cookies zu den primären Einfallstoren für Ransomware-Netzwerke gehört, müssen Sicherheitsabteilungen ihre Risikoanalysen anpassen. Eine zeitgemäße IT-Governance darf den Schutz von Benutzerkonten nicht mehr allein auf Passwörter und Zwei-Faktor-Authentisierung stützen.

Das IT-Sicherheitsmanagement ist gefordert, eine vollständige Inventarisierung aller geschäftlich genutzten Cloud- und SaaS-Anwendungen durchzuführen, um deren Kompatibilität mit dem DBSC-Protokoll zu prüfen. Für Anwendungen, die das Verfahren noch nicht unterstützen, muss das verbleibende Risiko offener Cookies durch komplementäre Schutzmaßnahmen bewertet werden.

Zudem verlangt ein vorausschauendes Risikomanagement die kontinuierliche Überwachung der Unternehmensinfrastruktur auf unmanaged Endpoints oder veraltete Hardware, die kein TPM unterstützen, da diese Systeme eine kritische Schwachstelle in der Verteidigungslinie darstellen. Nur durch eine konsequentere Durchsetzung von Zero-Trust-Prinzipien und die Verpflichtung zur Nutzung moderner Hardware-Sicherheitsmodule lässt sich die Einhaltung strenger Compliance-Vorgaben garantieren und die geschäftliche Kontinuität vor den Folgen automatisierter Identitätsdiebstähle nachhaltig schützen