--- service: "Publicasta" schema_version: "1.0" article_id: 319 title: "Chrome bindet Sitzungen ans Gerät: gute Nachricht gegen Kontoübernahmen" language: "de" default_language: "en" canonical_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=de" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=de" api_url: "https://publicasta.com/api/public/v1/channels/good_tech_news/articles/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=de" channel_url: "https://publicasta.com/api/public/v1/channels/good_tech_news" channel_articles: "https://publicasta.com/api/public/v1/channels/good_tech_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-13T17:14:36+00:00" updated_at: "2026-08-13T17:14:36+00:00" translations: - language: "ar" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=ar" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=ar" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=ar" - language: "de" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=de" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=de" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=de" - language: "en" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=en" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=en" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=en" - language: "es" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=es" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=es" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=es" - language: "fr" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=fr" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=fr" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=pl" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=pl" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=ru" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=ru" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13?lang=zh" markdown_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.md?lang=zh" json_url: "https://publicasta.com/good_tech_news/chrome_device_bound_sessions_cookie_theft_2026_08_13.json?lang=zh" --- # Chrome bindet Sitzungen ans Gerät: gute Nachricht gegen Kontoübernahmen > Device-Bound Session Credentials beendet Cookie-Diebstahl nicht, kann gestohlene Sitzungen aber deutlich weniger portabel machen. Zwei-Faktor-Authentifizierung und Passkeys haben gestohlene Passwörter weniger entscheidend gemacht. Angreifer weichen deshalb auf das aus, was nach dem Login passiert: die Browser-Sitzung. Ein gestohlener Session-Cookie kann einen Kriminellen bereits authentifiziert erscheinen lassen, selbst wenn das Konto stark geschützt ist. Deshalb sind Device-Bound Session Credentials, kurz DBSC, in Chrome eine gute Techniknachricht: keine Wunderwaffe, sondern eine konkrete Antwort auf eine echte Schwäche in Protokoll, Browser und Gerät. ![Websitzung mit Sicherheitschip im Laptop und Server-Challenge verbunden](https://publicasta.com/storage/projects/16/pages/319/2026/08/5d588949-ee98-439d-a49c-a0c84010b832.webp) Der aktuelle Anlass kommt von Ars Technica, dem W3C-Entwurf, dem WICG-Explainer und der Google-Workspace-Hilfe zu Session Binding gegen Cookie-Diebstahl. Die Idee ist verständlich: Wenn eine unterstützte Website eine Sitzung erzeugt, erstellt der Browser einen kryptografischen Schlüssel, der auf dem ursprünglichen Gerät bleiben soll. Später kann der Server den Besitz dieses Schlüssels prüfen. Kopiert ein Infostealer nur den Cookie auf einen anderen Rechner, sollte das allein nicht mehr reichen. ## Die Lücke Ein Session-Cookie ist Bequemlichkeit. Nach dem Login fragt die Website nicht bei jedem Seitenaufruf nach Passwort und zweitem Faktor. Der Browser sendet den Cookie, der Server erkennt die Sitzung. Das Problem: Der Cookie verhält sich oft wie ein bearer token. Wer ihn trägt, kann ihn verwenden. DBSC fügt eine Bedingung hinzu: Bestimmte Cookies werden nur aktualisiert oder bestätigt, wenn der Browser den privaten Schlüssel dieser Sitzung nachweist. Das ist relevant, weil sich Angriffe verschoben haben. Phishing bleibt, aber Passkeys, Security Keys und starke MFA machen es gegen wertvolle Konten weniger zuverlässig. Sitzungsdiebstahl umgeht diesen Fortschritt. Malware, bösartige Erweiterungen, adversary-in-the-middle-Kits und schlecht geschützte Logs können einen angemeldeten Browser zur Tokenquelle machen. DBSC verringert den Wert einer Kopie außerhalb des Geräts. ## Die Technik ohne Mythos Der Server weist den Browser an, eine geschützte Sitzung zu registrieren. Der Browser erzeugt ein Schlüsselpaar für diese Sitzung. Der private Schlüssel liegt nach Möglichkeit in einem geschützten Gerätebaustein: öffentliche Chrome-Unterlagen nennen TPM unter Windows, technische Analysen sprechen über Secure Enclave auf Apple-Plattformen. Der konkrete Mechanismus kann variieren; entscheidend ist, dass der private Schlüssel nicht wie eine normale Datei exportierbar ist. Bei Registrierung und späteren Aktualisierungen signiert der Browser eine Challenge. Der Server braucht keine dauerhafte Hardwareidentität. Der WICG-Text sagt ausdrücklich, dass die TPM-Zertifikatskette nicht gesendet wird, weil sie präzises Fingerprinting ermöglichen würde. Der Server soll nur prüfen, ob dieser Browser den passenden Sitzungsschlüssel noch besitzt. Das ist nicht dasselbe wie ein Passkey. Der Passkey schützt den Login. DBSC schützt die Fortsetzung der Sitzung nach dem Login. Die Schichten ergänzen sich: eine sichert die Tür, die andere macht den gestohlenen Ausweis nach der Tür weniger nützlich. ## Konkreter Nutzen Viele Schutzmaßnahmen hängen davon ab, dass Nutzer im schlechtesten Moment richtig reagieren: Link nicht anklicken, falsche Domain erkennen, verdächtige Push-Anfrage ablehnen. DBSC ist stark, weil die Hauptprüfung automatisch läuft. Hat der Angreifer nur den Cookie, fehlt ihm der private Schlüssel für die Server-Challenge. Für Unternehmen kann das viel bewirken. Eine gestohlene Sitzung in Mail, Cloud-Konsole, CRM, Finanzsystem oder Admin-Panel kann Dokumente, Kundendaten und Konfigurationen öffnen. Google Workspace beschreibt Session Binding als Schutz gegen Cookie-Diebstahl: nutzbar auf dem verwalteten Gerät, deutlich weniger nutzbar nach dem Kopieren. Wenn sich das Muster verbreitet, verlieren Infostealer-Kampagnen an Ertrag. ## Grenzen DBSC macht Malware auf demselben Gerät nicht harmlos. Sie kann über den echten Browser handeln, frische Tokens abwarten, Erweiterungen missbrauchen oder die geschützte Umgebung als Signier-Orakel nutzen. Der WICG-Explainer nennt anhaltenden Zugriff auf einen kompromittierten User Agent ausdrücklich als Grenze. Das realistische Versprechen ist enger: temporärer Zugriff soll nicht automatisch zu dauerhaftem Fernzugriff werden. Auch schwache Kontowiederherstellung, Serverkompromittierung, gefährliche Erweiterungen, Social Engineering gegen Support oder zu lange Sitzungsdauer werden nicht gelöst. Website, Browser, Gerät und Unternehmensprozesse müssen zusammenpassen. ## Datenschutz Fingerprinting ist der richtige Einwand. Eine stabile TPM- oder Secure-Enclave-Identität im Web wäre gefährlich. DBSC versucht genau das zu vermeiden: getrennte Schlüssel pro Sitzung, keine Verknüpfbarkeit verschiedener Schlüssel mit demselben Gerät und keine TPM-Zertifikatskette an den Server. Hintergrundaktualisierungen sollen durch Anfragekontext, Cookie-Zugriff und aktive Website begrenzt bleiben. Diese Versprechen brauchen Kontrolle durch Browseranbieter, Datenschutzforscher und Standards-gremien. Die gute Nachricht ist nicht blindes Vertrauen, sondern ein öffentliches Design, das das Risiko benennt. Akzeptabel ist DBSC nur mit sitzungs- oder sitegebundenen Schlüsseln, ohne stabile Hardwarekennung, mit klaren Unternehmenskontrollen und verständlicher Wiederherstellung. ## Was jetzt sinnvoll ist Ars berichtete über Unterstützung in neuen Chrome-Versionen für Windows und macOS, aber auch über begrenzte Verfügbarkeit. WICG und W3C zeigen aktive Standardisierung, keine universelle Webbasis. Admins sollten Google-Workspace-Hinweise verfolgen, kritische Dienste mit hohem Sitzungsrisiko inventarisieren und Anbieter nach Session Binding, Logs, Recovery und Datenschutz fragen. Nutzer müssen keinen magischen Schalter suchen. Browser aktualisieren, Passkeys oder starke MFA nutzen, riskante Erweiterungen entfernen und Gerätekompromittierung ernst nehmen bleibt richtig. Wenn DBSC gut ausrollt, ist das beste Ergebnis unspektakulär: weniger außerhalb des Geräts wiederverwendbare Cookies, weniger Login-Schleifen und mehr Standardfehlschläge für Angreifer. ## Fazit DBSC schützt eine Phase, die zu lange hieß: Wer den Cookie hat, hat die Sitzung. Es beendet Kontoübernahmen nicht, macht aber einen sehr praktischen Weg weniger zuverlässig: Sitzung stehlen, woanders wiederholen, eintreten. In der Sicherheit ist es ein echter Fortschritt, wenn ein billiger Angriff weniger portabel und besser erkennbar wird. ## Quellen Ars Technica, Dan Goodin, 11. August 2026; W3C Editor's Draft Device Bound Session Credentials; WICG DBSC Explainer und Repository; Google Workspace Hilfe zu Session Binding; Scott Helme; Corbado zu DBSC, Passkeys und Sitzungssicherheit; Hacker News item 49268757 als Debatte zu TPM, Secure Enclave, Passkeys und Fingerprinting.