Farewell to stolen Cookies jetzt Authentifizierung ist mit dem Gerät in Chrome verbunden

Seit Jahren suchen die Angreifer nach einfachen und lukrativen Möglichkeiten, auf Online-Konten zuzugreifen: Statt Passwörter zu brechen, stehlen sie, was bereits vorübergehenden Zugriff auf einen Dienst gewährt: Session-Cookies. Diese Token, wenn lange genug, erlauben einem Eindringling, ein Konto einzugeben, ohne das Passwort kennen zu müssen, und oft im Cybercrime-Markt enden. Um dieser Bedrohung entgegenzuwirken, hat Google beschlossen, diese Sitzungen an die eigene Maschine des Benutzers zu binden, indem eine Technologie verwendet wird, die jetzt beginnt, alle Chrome-Benutzer unter Windows zu erreichen.

Device Bound Session Credentials (DBSC) ist die Antwort von Google auf das Problem "Session Exfiltration". In einfachen Worten, anstatt einfach einen Cookie genug zu besitzen, um ein Konto einzugeben, Chrome kann den Browser benötigen, um kryptisch zu demonstrieren, dass das Cookie von dem gleichen Gerät verwendet wird, das es erzeugt. Wenn also eine Malware das Cookie kopiert und an einen vom Angreifer kontrollierten Server sendet, verliert dieser Cookie den Wert, weil er nicht beweisen kann, dass er vom legitimen Computer stammt.

Die Technik basiert auf Sicherheitsmodulen, die in der Hardware vorhanden sind: In Windows wird das Trusted Platform Module (TPM) verwendet und auf Apple-Computern wäre das Äquivalent die Secure Enclave. Diese Umgebungen ermöglichen die Erstellung von privaten kryptographischen Schlüsseln, die nicht außerhalb des Geräts exportiert werden können. Wenn der Server ein Sitzungstoken ausgeben oder erneuern muss, fordert es Chrome, den Besitz dieses privaten Schlüssels zu testen. Chrome Zeichen oder beteiligt sich an einem Protokoll, das zeigt, dass Besitz, ohne den Schlüssel selbst zu offenbaren. Das Ergebnis ist, dass Cookies ephemeral werden und mit der Maschine verbunden, nicht übertragbar.

Google startete DBSC in Open Beta-Version zu testen und kündigt nun an, dass die Funktionalität allen Windows-Benutzern zur Verfügung steht, die Chrome 146 aktualisieren; die Unterstützung für macOS wird in einer späteren Version des Browsers ankommen. Das Unternehmen erklärt, dass, wenn das Gerät keine sichere Schlüsselspeicherung hat, DBSC den Authentifizierungsfluss nicht bricht: es kehrt einfach zum traditionellen Verhalten zurück, um den Benutzer nicht ohne Zugriff zu verlassen. Dieser reibungslose Übergang ist wichtig, um keine Reibung in älteren Geräten oder virtualisierten Umgebungen zu verursachen, in denen physische TPM nicht existiert.

Die Funktionstreiber behaupten, eine signifikante Verringerung der Sitzungsdiebstahlversuche aus den ersten Tests beobachtet zu haben, was darauf hindeutet, dass die Bindesitzungen zu Hardware die Rentabilität der Geschäfte für Steler-Operatoren erheblich beeinträchtigen können - Malware-Familien, die Daten aus dem System extrahieren. Wenn Sie verstehen wollen, wie diese bösartigen Programme funktionieren und warum sie so gefährlich sind, gibt es technische Analysen, die zum Beispiel in Malharebytes Blog über Familien wie Vidar und andere ähnliche Bedrohungen zugänglich sind: Malharebytes Labs.

DBSC tritt nicht im Vakuum auf: Es ist Teil einer größeren Tendenz zur "device-linked" Authentifizierung und der weit verbreiteten Verwendung von sicheren Hardware-Elementen. In diesem Ökosystem gibt es Links zu Standards und Technologien wie WebAuthn und FIDO Alliance, die versuchen, die Passwortabhängigkeit zu reduzieren und kryptographische Überprüfung auf die tägliche Authentifizierung zu bringen. Wenn Sie daran interessiert sind, die Standards der modernen Authentifizierung zu vertiefen, bietet die FIDO Alliance eine zugängliche Dokumentation: fidoalliance.org.

Datenschutz und Grenzen. Google hat die Architektur mit klaren Datenschutzkriterien entworfen: Die Überprüfung erfolgt mit einem Schlüssel pro Sitzung und, nach dem Unternehmen, beinhaltet nicht das Senden von Gerätekennungen oder Attestationsdaten, die es erlauben, die Aktivität zwischen Websites zu korrelieren. Mit anderen Worten, die Absicht ist, die Sicherheit zu verbessern, ohne Sitzungsschlüssel in einen Folgemechanismus zu verwandeln. Dies ist wichtig, weil eine Lösung, die Sitzungen schützen würde, aber eine Benutzerprofilierung ermöglichen würde, inakzeptabel gewesen wäre.

Es gibt jedoch praktische Einschränkungen, die berücksichtigt werden sollten. Wenn ein Angreifer eine vollständige Kontrolle über das Gerät erhält (z.B. mittels eines Rootkits oder eines verlängerten physischen Zugriffs), kann es lokale Zustände wiederherstellen oder manipulieren und möglicherweise Abmildern entfernen. Auch virtuelle Umgebungen und Maschinen ohne physische TPM stellen Herausforderungen dar: Der Mechanismus deaktiviert einfach und kehrt zum traditionellen Verhalten zurück, um die Usability zu erhalten. Es gibt auch operationelle Probleme für Unternehmen: Gerätemanagement, Benutzermigration zwischen Maschinen oder Anmelderichtlinien können komplementäre Lösungen (z.B. Key Scrows oder Restaurierungsverfahren) erfordern, die sorgfältig gestaltet werden sollten.

Auf institutioneller Ebene ist die Ankunft von DBSC ein interessanter Punkt für Sicherheitsausrüstung und Administratoren: Es kann das Risiko, das mit gestohlenen Cookies verbunden ist, reduzieren, aber es ersetzt keine anderen Verteidigungen. Die Kombination mehrerer Schichten - häufige Browser-Updates, Multifaktor-Authentifizierung (MFA), Endpunkt-Schutz und Benutzer-Training auf Malware-Risiko - bleibt die robusteste Strategie. Um die Rolle von TPM in Windows besser zu verstehen und wie es in die Vertrauenskette integriert ist, bietet Microsoft hier technische Dokumentationen: Microsoft Lernen - TPM. Apple dokumentiert seinerseits seine Secure Enclave auf seinen Entwickler-Sicherheitsseiten: Secure Enclave - Apple.

Ein weiterer positiver Aspekt ist, dass Google mit Microsoft gearbeitet hat, um das Design mit einem breiteren Ziel vereinbar zu machen: die Technik in etwas Interoperables zu verwandeln und, soweit möglich, ein offener Standard zu werden, den andere Browser und Dienste annehmen können. Dieser kollaborative Ansatz erhöht die Wahrscheinlichkeit, dass der Schutz nicht auf ein einzelnes Ökosystem beschränkt wird und hoffentlich die Sicherheit des gesamten Internets erhöht.

Für den durchschnittlichen Benutzer ist die Beratung direkt: halten Chrome up-to-date (Schutz kommt mit neueren Versionen), verwenden MFA auf allen Konten, die es erlauben und betrachten physische Sicherheitsschlüssel, wo möglich. In Unternehmensumgebungen sollten IT-Teams beurteilen, wie DBSC in ihre Geräteverwaltungsrichtlinien und die Kontoerholung einpasst. Ziel ist es nicht, gute Praktiken zu ersetzen, sondern ein Belichtungsfenster zu reduzieren, das bisher besonders kostengünstig für Angreifer war.

Wenn Sie die offiziellen Notizen von Chrome-Updates lesen oder die Sicherheitsinformationen von Google, die Chrome Anzeigenseiten und Google Security-Blog sind gute Ausgangspunkte: Chrome Releases und Google Security Blog. Die Kombination dieser Teile - Browser-Dokumentation, Sicherheits-Hardware-Informationen und Bedrohungsanalyse - hilft zu verstehen, warum das Binden von Sitzungen zum Gerät eine echte Verbesserung im Kampf gegen Sitzungsdiebstahl bedeuten kann.