LONDON (IT BOLTWISE) – Chrome erweitert die Browser-Sicherheit mit device-bound session credentials (DBSCs). Die Funktion bindet Sitzungs-Token an kryptografische Schlüssel, die in hardware-geschützten Bereichen des Geräts verbleiben. Damit wird das reine Kopieren von Session-Cookies deutlich weniger wirksam, weil Angreifer DBSC-Challenges nicht ohne den privaten Schlüssel beantworten können. Für Windows und macOS sind die ersten Varianten bereits in neueren Chrome-Versionen verfügbar, aktuell jedoch nur für ausgewählte Nutzer.
Der nächste Schritt in Richtung weniger Account-Takeovers kommt nicht primär über neue Passwort-Features, sondern über eine Änderung, die auf den ersten Blick „nur“ die Sitzungsverwaltung betrifft: Google hat in Chrome device-bound session credentials (DBSCs) ergänzt. Die Idee zielt auf eine Schwachstelle, die trotz 2FA, Passkeys und anderer Härtungen noch immer eine zentrale Rolle spielt: Session-Cookies. Wenn eine Website einen eingeloggten Status in Form eines Cookies setzt, beschleunigt dieser Mechanismus zwar den Seitenwechsel, macht aber genau diese Cookies für Angreifer so attraktiv. DBSCs versuchen, den Wert gestohlener Cookies zu entkoppeln, indem sie den Zugriff an einen gerätespezifischen Schlüssel binden.
Technisch betrachtet wandert bei DBSCs ein eindeutiger Verschlüsselungsschlüssel in einen hardwaregeschützten Bereich, der direkt im jeweiligen Gerät „residiert“. Auf Windows-Systemen heißt diese Schutzzone TPM (Trusted Platform Module), auf macOS und iOS wird sie als Secure Enclave bezeichnet; andere Plattformen verwenden entsprechend andere Namen und Implementierungen. Wichtig ist dabei weniger das Branding als die Eigenschaft: Der Schlüssel soll in einer Umgebung isoliert sein, die ihn vor Extraktion schützt. Für die Praxis bedeutet das, dass der Browser beim Aufbau und Nachweis einer Session nicht nur einen Cookie „mitliefert“, sondern einen Challenge-Response-Mechanismus nutzt, bei dem die Antwort mit dem im geschützten Speicher verwahrten privaten Schlüssel signiert werden muss.
Genau an dieser Stelle setzen DBSCs an den typischen Angriffspfaden an, die sich mit der Verbreitung moderner Authentifizierungsmethoden verlagert haben. Sobald ein einzelnes Passwort nicht mehr genügt, verlieren klassische Phishing-Abläufe häufig ihren unmittelbaren Effekt. Angreifer greifen stattdessen immer öfter zu Infostealer-Malware oder setzen auf adversary-in-the-middle-Taktiken, deren gemeinsamer Nenner das Stehlen von Session-Cookies ist. Das Grundmuster bleibt dabei simpel: Der Angreifer übernimmt im Idealfall den Browserkontext durch das Kopieren des Cookies, überträgt ihn in eine eigene Sitzung und versucht so, die gleiche Berechtigung „vorzutäuschen“ – zumindest zeitweise. DBSCs kontern diese Logik, weil der Browser eine Cookie-gebundene Signaturanforderung erfüllen muss, die ohne Zugriff auf den privaten Schlüssel nicht korrekt beantwortet werden kann.
Der Ablauf lässt sich in der Sprache des Web-Sicherheitsmodells so zusammenfassen: Sobald ein Server eine Session auf Basis des Cookies aufsetzt, muss der Browser ein Cookie-Element in eine signierte Antwort einbringen. Der Server akzeptiert die resultierende Antwort nur dann, wenn sie mit dem privaten Schlüssel erstellt wurde, der sicher im TPM oder in der Secure Enclave verbleibt. Apple beschreibt diesen Punkt sinngemäß so, dass das TPM bzw. die Secure Enclave den privaten Schlüssel nicht herausgibt; damit kann ein Angreifer den privaten Schlüssel nicht extrahieren, selbst wenn er den Cookie kopiert. Scott Helme, Researcher und Gründer von Report URI, brachte es in einem Kommentar auf den Punkt: Der Angreifer könne zwar den Cookie stehlen, könne aber eine DBSC-Challenge nicht signieren, weil der private Schlüssel auf dem Gerät sicher bleibt.
Für die Nutzerseite ist die Verfügbarkeit derzeit noch selektiv. Laut den Angaben im Text sind DBSCs in Chrome Version 147 für Windows und in Version 150 für macOS enthalten; selbst dort schaltet Google sie zunächst nur für einen limitierten Kreis von Nutzerinnen und Nutzern ein. Wer prüfen möchte, ob die Funktion im eigenen Browser aktiv ist, kann das laut Anleitung über die Developer Tools tun: Application-Tab öffnen und nach dem Eintrag „device bound sessions“ suchen, wenn man in einer Site eingeloggt ist, die DBSCs unterstützt. Damit wirkt die Einführung wie ein kontrolliertes Rollout-Testing im Feld statt wie eine „Day-one“-Umstellung für alle – plausibel, weil solche Änderungen am Authentifizierungsfluss in sehr unterschiedlichen Geräte- und Ecosystem-Konstellationen beobachtet werden müssen.
Über Chrome hinaus bleibt die Richtung klar: Die Funktion gehört in eine breitere Bewegung weg von der Abhängigkeit von einem „shared secret“, das als alleinige Hürde für Angreifer besonders attraktiv bleibt. In diesem neuen Modell hält der Server den öffentlichen Schlüssel vor, während der Browser die private Schlüsselkomponente im hardwaregeschützten Bereich nutzt, um eine Authentifizierungsbehauptung (authentication assertion) zu signieren. Passkeys arbeiten dabei konzeptionell ähnlich, allerdings nicht identisch in jedem Detail. Interessant ist auch der Standardisierungsprozess: Im Umfeld von WebAppSec wird die Arbeit für DBSCs als W3C-Standard vorangetrieben, mit öffentlich einsehbaren Ressourcen unter https: //w3c.github.io/webappsec-dbsc/. Für Unternehmen ist das relevant, weil künftige Interoperabilität die Sicherheit schneller in heterogene Client-Landschaften tragen kann – also dort, wo nicht nur Chrome, sondern auch andere Chromium-basierte Browser oder alternative Browserwelten eine Rolle spielen.
Wann andere Browser die gleiche Mechanik übernehmen, ist im Text offen gelassen, allerdings deutet die Formulierung darauf hin, dass man DBSCs nicht als isoliertes Chrome-Experiment verstehen sollte. Für Sicherheitsverantwortliche heißt das: Session-Cookies werden weiterhin existieren, aber die Erwartung an „Wiederverwendbarkeit“ im Angreifer-Kontext verschiebt sich. Unabhängig davon, ob künftig auch andere Browser DBSCs einführen, bleibt ein Kernthema bestehen: Mit hardwaregebundener Schlüsselmaterial-Absicherung wird der Angriff weniger von Datenkopie abhängen und stärker von einem echten, gerätespezifischen Zugriff. Das ist ein Qualitätsgewinn für die Praxis – vor allem gegen genau die Angriffsvariante, die sich nach der breiten Adoption von 2FA und Passkeys neu in den Vordergrund gedrängt hat.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Chrome führt device-bound session credentials ein: Schutz gegen Cookie-Diebstahl" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Chrome führt device-bound session credentials ein: Schutz gegen Cookie-Diebstahl" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Chrome führt device-bound session credentials ein: Schutz gegen Cookie-Diebstahl« bei Google Deutschland suchen, bei Bing oder Google News!