--- url: 'https://www.corbado.com/de/blog/device-bound-session-credentials-dbsc' title: 'Device Bound Session Credentials (DBSC) erklärt' description: 'Erfahren Sie, wie Device Bound Session Credentials (DBSC) Session Hijacking & Cookie-Diebstahl verhindern. Infos zu Browser-Support und Unternehmenssicherheit.' lang: 'de' author: 'Vincent Delitz' date: '2026-06-15T13:56:24.997Z' lastModified: '2026-06-16T06:02:12.946Z' keywords: 'Device Bound Session Credentials, DBSC, Session Hijacking Prävention, Cookie-Diebstahl Schutz, TPM-Sitzungsbindung' category: 'Authentication' --- # Device Bound Session Credentials (DBSC) erklärt **Browser-Unterstützungsstatus** > **Aktuell (April 2026):** [Chrome](https://www.corbado.com/de/blog/digital-credentials-api) 146 veröffentlicht > [DBSC in allgemeiner Verfügbarkeit auf Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) > und führt die Funktion damit aus der Origin Trial heraus. Die Unterstützung für macOS > (über die [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) folgt in einer kommenden > [Chrome](https://www.corbado.com/de/blog/digital-credentials-api)-Version. Google hat außerdem eine öffentliche > Roadmap für föderierte Identitäten (Cross-Origin > [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso)-Bindungen), erweiterte Registrierung (mTLS / > Hardware-Schlüssel) und softwarebasierte Schlüssel für Geräte ohne sichere Hardware > angekündigt. | Browser | Windows | macOS | Linux | Android | iOS | Status | | ----------- | ----------------------- | ---------------------------- | ----------------- | ----------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 In Kürze (Secure Enclave) | ❌ | ❌ | ❌ | [GA auf Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (April 2026), macOS in kommender Version | | **Edge** | ⏸️ Testphase beendet | ❌ | ❌ | ❌ | ❌ | Origin Trial endete im Okt. 2025, kein GA angekündigt | | **Safari** | N/A | 🔄 In Evaluierung | N/A | N/A | 🔄 In Evaluierung | WebKit diskutiert, keine Implementierung angekündigt | | **Firefox** | 🔄 In Beobachtung | 🔄 In Beobachtung | 🔄 In Beobachtung | 🔄 In Beobachtung | 🔄 In Beobachtung | Wird evaluiert, keine Verpflichtung zur Implementierung | **Legende:** ✅ Allgemein verfügbar (GA) | 🚧 Angekündigt / in Entwicklung | ⏸️ Testphase beendet | 🔄 In Evaluierung/Beobachtung | ❌ Noch nicht verfügbar **Hinweis:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) ist ab [Chrome](https://www.corbado.com/de/blog/digital-credentials-api) 146 (April 2026) auf Windows mit TPM allgemein verfügbar. Die Unterstützung für macOS über die [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) wird als Nächstes eingeführt. Googles veröffentlichte Roadmap umfasst auch softwarebasierte Schlüssel, um den Schutz auf Geräte ohne dedizierte sichere Hardware auszuweiten. **Hauptvorteile: DBSC vs. aktuelles Modell** | **Funktion** | **Aktuelles Cookie-Modell** | **DBSC-Modell** | | ----------------------- | ----------------------------- | ------------------------------------------------------- | | **Token-Typ** | Inhaber (Besitz = Zugriff) | Gebunden (Besitz + Schlüssel = Zugriff) | | **Folge bei Diebstahl** | Vollständige Kontoübernahme | Nutzloses Token (kann nicht erneuert werden) | | **Sitzungsdauer** | Kurz (aus Sicherheitsgründen) | Lang / unendlich (Secure by Design) | | **Reibung für Nutzer** | Hoch (häufige Logins) | Gering (unsichtbare Sicherheit) | | **MFA-Umgehung** | Anfällig (Pass-the-Cookie) | Resistent (Gerät erforderlich) | | **Widerruf** | Langsam (Warten auf Ablauf) | Fast in Echtzeit (schlägt bei nächster Erneuerung fehl) | ## Key Facts - **DBSC** bindet Websitzungen an einen kryptografischen Schlüssel auf dem Gerät, wodurch gestohlene Cookies nutzlos werden, da sie von einem anderen Gerät aus nicht erneuert werden können. - Der Browser speichert einen nicht exportierbaren privaten Schlüssel in einem **TPM** und signiert Server-Herausforderungen alle 5 Minuten, um den Gerätebesitz ohne Nutzerinteraktion nachzuweisen. - Im Gegensatz zum **Token Binding**, das aufgrund der Komplexität der TLS-Schicht-Infrastruktur scheiterte, arbeitet DBSC auf der HTTP-Anwendungsschicht und funktioniert transparent mit vorhandenen Load Balancern und CDNs. - **Chrome 146 veröffentlicht DBSC in allgemeiner Verfügbarkeit (GA) auf Windows (April 2026)**, wobei die Unterstützung für die macOS Secure Enclave in einer kommenden Version folgt. Die veröffentlichte Roadmap von Google umfasst auch föderierte Identitäten (Cross-Origin SSO-Bindungen), erweiterte Registrierung (mTLS / Hardware-Schlüssel) und softwarebasierte Schlüssel für Geräte ohne sichere Hardware. Safari und Firefox befinden sich noch in der Evaluierung; die Origin Trial von Edge endete im Oktober 2025 ohne Ankündigung einer allgemeinen Verfügbarkeit. ## 1. Einführung: Device Bound Session Credentials (DBSC) Die Architektur des World Wide Web wurde auf dem Prinzip der Zustandslosigkeit gegründet. Als HTTP erstmals entworfen wurde, behielt es zwischen Anfragen keine Informationen über Nutzer bei. Um dies zu lösen, wurde das "Cookie" erfunden – ein kleines Datenpaket, das von einer Website gesendet und auf dem Computer des Nutzers gespeichert wird, um bei jeder nachfolgenden Anfrage an die Website zurückgesendet zu werden. Jahrzehntelang diente dieser Mechanismus als Grundlage der Sitzungsverwaltung. Wenn sich ein Nutzer anmeldet, validiert der Server seine Anmeldedaten und stellt ein Cookie aus. Dieses Cookie fungiert als "Inhaber-Token" (Bearer Token). In der physischen Welt ist ein Inhaberpapier ein Dokument, das dem Inhaber die Rechte oder Vermögenswerte einräumt, die es repräsentiert; wer die Anleihe besitzt, dem gehört die Anleihe. Ähnlich gilt in der digitalen Welt von HTTP: Wer das Cookie besitzt, ist der Nutzer. Diese Inhabereigenschaft ist gleichzeitig der größte Nutzen des Webs und seine tiefgreifendste Schwachstelle. Die [Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) der gesamten Sitzung – und damit auch die [Identität](https://www.corbado.com/de/blog/digital-credentials-api), die Daten und die finanziellen Vermögenswerte des Nutzers – beruht vollständig auf der Geheimhaltung dieser Cookie-Zeichenfolge. Wenn ein böswilliger Akteur diese Zeichenfolge kopieren kann, kann er sich von jedem Gerät, überall auf der Welt, als Nutzer ausgeben und die anfänglichen Authentifizierungsprüfungen vollständig umgehen. Diese spezifische Schwachstelle hat eine Untergrundwirtschaft im industriellen Maßstab für "Cookie-Diebstahl" und "[Session Hijacking](https://www.corbado.com/blog/3ds-authentication-failed)" (Sitzungsübernahme) hervorgebracht. Während die Branche die "Vordertür" der [Authentifizierung](https://www.corbado.com/de/blog/komplexe-passwoerter-bald-geknackt) durch die Einführung von [FIDO](https://www.corbado.com/de/blog/emv-3ds-acs-passkeys-fido-und-spc)-Standards (Fast Identity Online) und Passkeys erfolgreich härtet, verlagern Angreifer ihren Fokus auf die "Hintertür": die aktive Sitzung. Das [Phishing](https://www.corbado.com/glossary/phishing) eines Passworts wird schwieriger, aber der Diebstahl eines Sitzungscookies bleibt gefährlich effektiv. Die Antwort der Branche auf diese eskalierende Bedrohung sind **Device Bound Session Credentials (DBSC)**. [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) stellt einen Paradigmenwechsel bei der Aufrechterhaltung von Websitzungen dar. Es schlägt vor, sich von einfachen Inhaber-Tokens abzuwenden und hin zu einem Modell überzugehen, bei dem die Sitzung [kryptografisch an das Gerät gebunden ist](https://www.w3.org/TR/dbsc/). Mit der [Veröffentlichung von DBSC in GA auf Windows mit Chrome 146 (April 2026)](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) ist der Standard von einer experimentellen zu einer produktionsreifen Funktion übergegangen, die Webteams heute einsetzen können. Chrome nutzt TPMs auf Windows und führt als Nächstes die Unterstützung für die Secure Enclave auf macOS ein; die Spezifikation selbst ist agnostisch hinsichtlich der Schlüsselspeicherung und erfordert lediglich, dass sie "robust gegenüber der beschriebenen Bedrohung" ist. Dies macht gestohlene Cookies weitaus weniger wertvoll. Sie können von einem anderen Gerät ohne den gebundenen Schlüssel nicht erneuert werden. Dieser Artikel bietet eine umfassende Analyse von [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc), die für Sicherheitsarchitekten, Produktmanager und Entwickler konzipiert ist. Er untersucht die technische Architektur, die geschäftlichen Auswirkungen von "reibungsloser [Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden)", die Beziehung zu aufkommenden Standards wie Shared Signals (CAEP/RISC) und wie sich Unternehmen mithilfe von Plattformen wie Corbado auf diese Zukunft vorbereiten können. **Schlüsselfragen, die dieser Artikel beantwortet** 1. Warum scheitert die aktuelle Sitzungsverwaltung daran, Kontoübernahmen zu verhindern? 2. Wie unterscheidet sich DBSC von bestehenden "Secure"-Cookies und HttpOnly-Flags? 3. Wie arbeiten DBSC und Passkeys für einen stärkeren [Phishing](https://www.corbado.com/glossary/phishing)-Schutz zusammen? 4. Was ist mit Token Binding passiert und warum ist DBSC dort erfolgreich, wo es gescheitert ist? 5. Was sind die geschäftlichen Auswirkungen und der ROI für Produktmanager? 6. Welche Browser und Betriebssysteme unterstützen DBSC heute? 7. Wie können Organisationen DBSC implementieren, ohne von Grund auf neu zu entwickeln? 8. Wie ist das Verhältnis zwischen DBSC, DPoP und [OAuth 2.0](https://www.corbado.com/glossary/oauth2)? 9. Wie lässt sich DBSC in Shared Signals (CAEP/RISC) für die Bedrohungsreaktion in Echtzeit integrieren? ## 2. Die Kernprobleme und -lösungen verstehen Um die Komplexität dieses neuen Standards zu durchdringen, müssen wir zunächst die grundlegenden Probleme der aktuellen Sitzungsverwaltung verstehen und wie DBSC Lösungen bietet. Jeder dieser Bereiche stellt eine kritische Schwachstelle oder Einschränkung dar, die DBSC adressiert. ### 2.1 Scheitern der aktuellen Sitzungsverwaltung Das grundlegende Scheitern der aktuellen Sitzungsverwaltung ist die "Portabilität" des Vertrauens. Wenn ein Server ein Sitzungscookie ausstellt, stellt er im Grunde einen Pass aus, der für jeden funktioniert, der ihn besitzt. Obwohl Browser Abwehrmechanismen wie [HttpOnly und Secure Flags](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) implementiert haben (um JavaScript-Zugriff zu verhindern und die Übertragung über HTTPS sicherzustellen), schützen diese Abwehrmechanismen nur vor bestimmten Extraktionsvektoren wie Cross-Site Scripting (XSS) oder Netzwerk-Sniffing. Sie bieten keinen Schutz vor [Malware](https://www.corbado.com/glossary/malware), die auf dem Host-Gerät läuft. "Infostealer" sind Schadprogramme, die speziell dafür entwickelt wurden, die Cookie-Speicherdatei des Browsers auf der Festplatte zu lokalisieren, sie zu entschlüsseln (oft unter Verwendung der eigenen Anmeldedaten des Nutzers auf Betriebssystemebene) und die Inhalte auf einen Command-and-Control-Server zu exfiltrieren. Sobald der Angreifer im Besitz des Cookies ist, kann er einen [Pass-the-Cookie-Angriff](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) ausführen und das gestohlene Token in seinen eigenen Browser injizieren, um die Sitzung zu übernehmen. Der Server, der ein gültiges Cookie sieht, geht davon aus, dass die Anfrage legitim ist. ### 2.2 Der kryptografische Vorteil von DBSC gegenüber herkömmlichen sicheren Cookies DBSC führt einen zweiten Authentifizierungsfaktor in die Sitzungsverwaltungsschleife selbst ein. Im Gegensatz zu einem standardmäßigen sicheren Cookie, das ein statisches Geheimnis ist, besteht eine DBSC-Sitzung aus einem kurzlebigen Inhaber-Token und einem kryptografischen Besitznachweis. Der Browser generiert ein Public-Private-Key-Paar (öffentlicher und privater Schlüssel), das sicher auf dem Gerät gespeichert wird. Der Server bindet die Sitzung an den öffentlichen Schlüssel. Der Browser muss regelmäßig beweisen, dass er den privaten Schlüssel noch besitzt, indem er eine Herausforderung (Challenge) des Servers signiert. Die [Spezifikation erfordert eine Schlüsselspeicherung](https://www.w3.org/TR/dbsc/), die "robust gegenüber der beschriebenen Bedrohung" ist. Chrome verwendet TPM auf Windows, wenn verfügbar. Wenn ein Angreifer das Cookie von einem anderen Gerät stiehlt, kann er es nicht erneuern, weil er die erforderliche kryptografische Signatur nicht generieren kann. Der "Inhaber"-Aspekt wird auf ein sehr kurzes Zeitfenster minimiert, während der "Bindungs"-Aspekt langfristige Kontinuität bietet. ### 2.3 Synergie zwischen Passkeys und DBSC Passkeys und DBSC sind komplementäre Technologien, die verschiedene Phasen des Nutzerlebenszyklus sichern. Passkeys (FIDO2) lösen das _Authentifizierungsproblem_ durch den Nachweis der [Identität](https://www.corbado.com/de/blog/digital-credentials-api) zum Starten einer Sitzung ohne Passwörter und beseitigen so Credential [Phishing](https://www.corbado.com/glossary/phishing). DBSC adressiert das _Post-Authentifizierungsproblem_, indem es [Session Hijacking](https://www.corbado.com/blog/3ds-authentication-failed) durch Cookie-Diebstahl erheblich erschwert. Die [FIDO-Allianz stuft DBSC](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) als eine ergänzende Technologie ein, die die Messlatte gegen [Session Hijacking](https://www.corbado.com/blog/3ds-authentication-failed) "höher legt". Gemeinsam reduzieren sie die Angriffsfläche über den Login- und Sitzungslebenszyklus, obwohl DBSC nicht vor [Malware](https://www.corbado.com/glossary/malware) mit fortlaufendem Gerätezugriff oder Browser-in-the-Middle-Angriffen in Echtzeit auf demselben Gerät schützt. | Technologien | Remote-Phishing | Credential Stuffing | Token-Diebstahl | | -------------------------- | --------------- | ------------------- | --------------- | | **Passkeys** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Passkeys + DBSC / DPoP** | ✅ | ✅ | ✅ | **Wie Passkeys und DBSC zusammenarbeiten** | **Aspekt** | **Passkeys** | **DBSC** | **Kombinierter Nutzen** | | ------------------------ | ------------------------------------------------- | ------------------------------------------ | -------------------------------------------------- | | **Umfang** | Authentifizierung (Login) | Sitzungsverwaltung | End-to-End-Schutz | | **Geminderte Bedrohung** | Passwort-Phishing, Credential Stuffing | Remote Session Hijacking, Cookie-Diebstahl | Deutlich höhere Messlatte für Kontoübernahmen | | **Nutzererlebnis** | Passwortloser Login | Transparenter Sitzungsschutz | Nahtloses, sicheres Erlebnis | | **Schlüsselspeicher** | Gerätegebundene oder synchronisierte Anmeldedaten | Gerätegebunden (HSM wenn verfügbar) | Flexible Authentifizierung, rigide Sitzungsbindung | | **Einsatz** | Ersetzt Passwörter | Verbessert bestehende Sitzungen | Inkrementelle Sicherheitsverbesserungen | ### 2.4 Lehren aus dem Scheitern des Token Binding DBSC ist nicht der erste Versuch, dieses Problem zu lösen. "Token Binding" war ein früherer Standard, der versuchte, Cookies an die zugrunde liegende TLS-Verbindung (Transport Layer Security) zu binden. Obwohl kryptografisch solide, konnte sich Token Binding aufgrund seiner starken Abhängigkeit von der TLS-Schicht nicht durchsetzen. Im modernen Web werden TLS-Verbindungen oft an Load Balancern, CDNs oder Reverse Proxys beendet, während die Anwendungslogik auf dahinter liegenden Servern residiert. Die Weitergabe von Token Binding-Informationen durch diese komplexen Netzwerkschichten erwies sich als zu schwierig. DBSC lernt aus diesem Scheitern, indem [es vollständig auf der Anwendungsschicht (HTTP) operiert](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Es hängt nicht von der zugrunde liegenden Netzwerkverbindung ab und ist somit kompatibel mit vorhandenen Load Balancern, Proxys und Cloud-Infrastrukturen. ### 2.5 Geschäftliche Auswirkungen und ROI-Chancen Für Produktverantwortliche bietet DBSC die Möglichkeit, die [Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) zu erhöhen und gleichzeitig das Nutzererlebnis (UX) zu verbessern. In der Vergangenheit bedeutete hohe Sicherheit kurze Sitzungs-Timeouts, wodurch Nutzer gezwungen waren, sich häufig anzumelden (Reibung). Indem die Sitzung an das Gerät gebunden wird, wird das Risiko eines _Remote_-Cookie-Diebstahls erheblich reduziert. Unternehmen können längere Sitzungsdauern in Betracht ziehen, in dem Wissen, dass gestohlene Cookies von einem anderen Gerät nicht erneuert werden können. Allerdings schützt DBSC nicht vor Gerätediebstahl, persistenter [Malware](https://www.corbado.com/glossary/malware) auf dem Gerät oder Missbrauch durch einen böswilligen Nutzer, sodass Richtlinien zur Sitzungslebensdauer diese verbleibenden Risiken weiterhin widerspiegeln sollten. ## 3. Bedrohungslandschaft: Industrialisierung des Cookie-Diebstahls Um die Dringlichkeit hinter DBSC zu verstehen, muss man die Raffinesse der modernen Bedrohungslandschaft würdigen. Der Diebstahl von Sitzungscookies hat sich von einem Nischen-Hacker-Trick zu einer skalierbaren, automatisierten Industrie entwickelt. ### 3.1 Aufstieg von Infostealern ```mermaid graph TD A[Nutzer lädt
Schadsoftware herunter] -->|Ausführung| B[Infostealer aktiviert sich
auf Gerät] B --> C[Lokalisiert Browser-Daten] C --> D[Chrome/Edge/Firefox
Cookie-Speicher] C --> E[Passwort-Datenbank] C --> F[Krypto-Wallets] D --> G[Entschlüsselt mit
OS-Anmeldedaten] E --> G F --> G G --> H[Erstellt Protokolldatei
mit gestohlenen Daten] H --> I[Exfiltriert an C2-Server] I --> J[Dark-Web-Marktplatz] J --> K[Angreifer kauft Protokoll] K --> L[Importiert Cookie in
eigenen Browser] L --> M[Umgeht MFA] M --> N[Kontoübernahme
abgeschlossen] style A fill:#ff6b6b,color:#fff style B fill:#ff6b6b,color:#fff style N fill:#ff6b6b,color:#fff style J fill:#495057,color:#fff style M fill:#ffd43b,color:#000 ``` Malware-as-a-Service (MaaS) hat die Eintrittsbarriere für Cyberkriminelle gesenkt. "Infostealer" wie RedLine, Raccoon, Vidar und Taurus sind kommerziell verfügbare Malware-Stämme, die mit einem primären Ziel entwickelt wurden: Datenexfiltration aus Webbrowsern. Diese Stealer werden über Phishing-E-Mails, gecrackte Software oder bösartige Anzeigen verbreitet. Sobald sie installiert sind, zielen sie auf die spezifischen Dateipfade ab, in denen Browser wie Chrome, Edge und [Firefox](https://www.corbado.com/de/blog/digital-credentials-api) ihre Daten speichern. - **Das Ziel:** Die Cookie-Datenbank (normalerweise eine [SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide)-Datei) und die Anmeldedaten-Datenbank (gespeicherte Passwörter). - **Der Mechanismus:** Browser verschlüsseln diese Datenbanken mithilfe von Datenschutz-APIs (DPAPI unter Windows), die mit dem OS-Login des Nutzers verknüpft sind. Da die Malware _als der Nutzer_ läuft, kann sie die Entschlüsselung dieser Dateien trivial anfordern. - **Der Output:** Die Malware generiert ein "Protokoll" (Log) – eine Zip-Datei, die die entschlüsselten Cookies, Passwörter, Systeminformationen und manchmal Krypto-[Wallet](https://www.corbado.com/blog/digital-wallet-assurance)-Schlüssel enthält. ### 3.2 Markt für "Logs" Diese Logs werden aggregiert und auf Dark-Web-[Marktplätzen](https://www.corbado.com/passkeys-for-e-commerce) wie Genesis Market (vor der Abschaltung) und Russian Market verkauft. Käufer können nach Logs suchen, die aktive Cookies für bestimmte hochwertige Ziele enthalten: "Salesforce", "Gmail", "Bank of America" oder "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console". **Die Umgehung:** Der Wert eines Cookie-Logs liegt in seiner Fähigkeit, Multi-Faktor-[Authentifizierung](https://www.corbado.com/de/blog/komplexe-passwoerter-bald-geknackt) (MFA) zu umgehen. Die meisten [MFA](https://www.corbado.com/de/blog/medibank-datenleck)-Herausforderungen (SMS, TOTP, Push) treten nur während des _Login_-Vorgangs auf. Sobald die Sitzung etabliert und das Cookie ausgestellt ist, geht der Server davon aus, dass der Nutzer vertrauenswürdig ist. Ein Angreifer, der ein gültiges Sitzungscookie importiert, [gleitet direkt durch das MFA-Tor](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc), da er für den Server wie der Nutzer erscheint, der zu einem aktiven Tab zurückkehrt. ### 3.3 Google Workspace & Microsoft Entra Bedrohung Cloud-Produktivitäts-Suites sind Hauptziele. Ein gestohlenes Sitzungscookie für ein Google Workspace- oder [Microsoft Entra ID](https://www.corbado.com/de/blog/enterprise-passkey-einfuehrung-herausforderungen)- (früher Azure AD) Konto kann einem Angreifer Zugang zu Unternehmens-E-Mails, Dokumenten und internen Systemen verschaffen. [Googles eigene Threat Intelligence](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) hat einen massiven Anstieg des Cookie-Diebstahls als primären Vektor für den Zugriff auf Google-Konten gemeldet und diesen ausdrücklich als Treiber für ihre Investition in DBSC benannt. Sie stellen fest, dass Angreifer, während sie die 2-Faktor-Verifizierung (2SV) und Passkeys erzwingen, einfach ihre Taktik von Credential Phishing (das durch [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / Passkeys gestoppt wird) auf Cookie-Diebstahl (das durch [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / Passkeys oft nicht gestoppt wird) verlagert haben. ### 3.4 Grenzen des "Device Fingerprinting" In der Vergangenheit haben Risiko-Engines versucht, Sitzungsdiebstahl durch die Analyse von Geräte-Fingerabdrücken zu erkennen, indem sie den [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)-String, die Bildschirmauflösung, installierte Schriftarten und die IP-Adresse untersuchten. Wenn ein Sitzungscookie plötzlich von einer neuen IP mit einem leicht unterschiedlichen Canvas-Fingerabdruck auftaucht, könnte der Server es für ungültig erklären. **Das Problem:** Datenschutzinitiativen in Browsern (wie Safaris Intelligent Tracking Prevention und Chromes Privacy Sandbox) reduzieren aktiv die Entropie dieser Fingerabdrücke, um Ad-Tracking zu stoppen. Dies macht "gutes" Fingerprinting für die Sicherheit zunehmend schwierig. Darüber hinaus verwenden Angreifer nun "Anti-Detect-Browser", die es ihnen ermöglichen, diese Fingerabdrücke perfekt zu fälschen, um sie an das Profil des Opfers anzupassen, was die heuristische Erkennung ineffektiv macht. DBSC ersetzt dieses probabilistische Ratespiel durch einen deterministischen kryptografischen Nachweis. ## 4. Technische Architektur: Wie DBSC funktioniert [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) führt eine [standardisierte API und ein Protokoll](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) ein, um Sitzungen zu erstellen, die an einen Schlüssel auf dem Client-Gerät gebunden sind. Die Spezifikation erfordert eine Schlüsselspeicherung, die "robust gegenüber der beschriebenen Bedrohung" ist, ist aber agnostisch in Bezug auf die Implementierung. Chrome verwendet TPM auf Windows, wenn verfügbar. Dieser Abschnitt beschreibt die Mechanik, wie sie im W3C Working Draft und in der Chrome-Dokumentation definiert ist. ### 4.1 Kernkomponenten | **Komponente** | **Beschreibung** | **Rolle in DBSC** | | -------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **User Agent (Browser)** | Die Client-Anwendung (Chrome, Edge etc.). | Verwaltet das Schlüsselpaar, handhabt die HSM-Interaktion und fängt Netzwerkanfragen ab, um Nachweise anzuhängen. | | **Relying Party (Server)** | Die Webanwendung (z. B. Bankportal). | Gibt Herausforderungen aus, verifiziert Signaturen und verwaltet den Sitzungslebenszyklus. | | **Schlüsselspeicher** | Sicherer Speicher (TPM, Secure Enclave oder andere) | Speichert den privaten Schlüssel. Chrome nutzt TPM auf Windows wenn verfügbar; Spezifikation ist agnostisch zur Implementierung. | | **Sitzungscookie** | Ein standardmäßiges HTTP-Cookie. | Wird als Inhaber-Token verwendet, jedoch mit einer sehr kurzen Lebensdauer (z. B. 5-10 Minuten). | | **Besitznachweis** | Eine kryptografische Signatur. | Ein JWT, das vom Browser gesendet wird, um zu beweisen, dass er den privaten Schlüssel noch besitzt. | ### 4.2 DBSC Protokoll-Lebenszyklus Der DBSC-Lebenszyklus ermöglicht einen nahtlosen Übergang von einer Standardsitzung zu einer gebundenen Sitzung, wodurch Abwärtskompatibilität und progressive Verbesserung gewährleistet werden. ```mermaid sequenceDiagram participant User as Nutzer participant Browser participant HSM as HSM (TPM/Secure Enclave) participant Server Note over User,Server: Phase 1: Authentifizierung & Bindung User->>Browser: Login mit Anmeldedaten/Passkey Browser->>Server: Authentifizierungsanfrage Server->>Browser: Erfolg + DBSC-Registrierungs-Header Browser->>HSM: Schlüsselpaar generieren HSM->>Browser: Öffentlicher/Privater Schlüssel (privat nicht exportierbar) Browser->>Server: Öffentlichen Schlüssel registrieren (JWT-signiert) Server->>Server: Sitzung an öffentlichen Schlüssel binden Server->>Browser: Kurzlebiges Cookie (5 Min.) Note over User,Server: Phase 2: Normale Nutzung loop Jede Anfrage innerhalb von 5 Minuten Browser->>Server: Anfrage mit Cookie Server->>Browser: Antwort end Note over User,Server: Phase 3: Erneuerung (nach Ablauf) Browser->>Server: Anfrage mit abgelaufenem Cookie Server->>Browser: 401 + Challenge-Nonce Browser->>HSM: Challenge signieren HSM->>Browser: Signatur Browser->>Server: Signatur-Nachweis Server->>Server: Mit gespeichertem öffentlichen Schlüssel verifizieren Server->>Browser: Neues kurzlebiges Cookie Browser->>Server: Ursprüngliche Anfrage wiederholen Server->>Browser: Erfolgsantwort ``` #### 4.2.1 Phase 1: Initiierung und Bindung Der Bindungsprozess beginnt unmittelbar nachdem sich der Nutzer mit Standardmethoden (Passwort, Passkey etc.) erfolgreich authentifiziert hat. 1. **Server-Signal:** Nach erfolgreichem Login setzt der Server ein Sitzungscookie (wie üblich), fügt aber einen spezifischen Header hinzu, der die DBSC-Unterstützung anzeigt. ``` HTTP HTTP/1.1 200 OK Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register" ``` - Der Secure-Session-Registration-Header sagt dem Browser: "Ich unterstütze die Algorithmen ES256 und RS256. Bitte registriere eine gebundene Sitzung am Endpunkt /auth/dbsc/register." 2. **Schlüsselerzeugung:** Der Browser analysiert diesen Header. Er generiert ein neues asymmetrisches Schlüsselpaar (z. B. Elliptic Curve P-256), das sicher auf dem Gerät gespeichert wird. - **Implementierungshinweis:** Chrome verwendet TPM auf Windows, wenn verfügbar; die Spezifikation ist agnostisch hinsichtlich des Speichermechanismus und erfordert lediglich, dass er "robust gegenüber der beschriebenen Bedrohung" ist. - **Datenschutzumfang:** Der Schlüssel ist auf den Web-Ursprung (z. B. bank.com) beschränkt. Der Browser stellt sicher, dass dieser Schlüssel niemals für retailer.com verwendet wird, was websiteübergreifendes Tracking verhindert. 3. **Registrierungsanfrage:** Der Browser sendet eine Anfrage an den angegebenen Registrierungspfad. Diese Anfrage enthält den neu generierten **öffentlichen Schlüssel** in einem JSON Web Token (JWT), das mit dem privaten Schlüssel signiert ist (selbstsignierte Attestierung). ``` HTTP POST /auth/dbsc/register HTTP/1.1 Content-Type: application/jwt \.\.\ ``` 4. **Sitzungsbindung:** Der Server validiert die Signatur, um sicherzustellen, dass der öffentliche Schlüssel funktionsfähig ist. Er aktualisiert dann seine Datenbank, um die Sitzung des Nutzers (session_id=xyz123) mit diesem spezifischen öffentlichen Schlüssel zu verknüpfen. Von diesem Moment an ist die Sitzung "gebunden". #### 4.2.2 Phase 2: Kurzlebige Cookie-Schleife Um Sicherheit mit Leistung abzuwägen (sichere Schlüsseloperationen können Latenz hinzufügen), verwendet DBSC ein Dual-Token-System. 1. **Ausstellung:** Der Server gibt ein _neues_, kurzlebiges Cookie aus (z. B. gültig für 5 Minuten). Nennen wir dies access_token. 2. **Nutzung:** Der Browser verwendet dieses access_token für alle normalen Anfragen (Abrufen von Bildern, API-Aufrufe, Navigieren auf Seiten). Solange das Cookie gültig ist, werden keine kryptografischen Operationen durchgeführt. Dadurch bleibt das Surfen schnell. 3. **Ablauf:** Nach 5 Minuten läuft das access_token ab. #### 4.2.3 Phase 3: Erneuerung (Besitznachweis) Dies ist das Herzstück des Sicherheitsmechanismus. Wenn das kurzlebige Cookie abläuft, wird ein Angreifer auf einem anderen Gerät ausgesperrt, aber der legitime Nutzer (mit Zugriff auf den gebundenen Schlüssel) kann fortfahren. 1. **Erkennung:** Der Browser versucht eine Anfrage. Er bemerkt, dass das Cookie abgelaufen ist (oder der Server gibt einen 401 oder einen spezifischen Secure-Session-Challenge-Header zurück). 2. **Abfangen:** Der Browser _pausiert_ die Netzwerkanfrage. Er zeigt dem Nutzer keinen Fehler an. 3. **Erneuerungsanfrage:** Der Browser ruft automatisch den in der Sitzungskonfiguration definierten Erneuerungsendpunkt auf. - Der Server sendet eine kryptografische **Herausforderung** (eine Nonce). - Der Browser verwendet den gebundenen Schlüssel, um diese Herausforderung zu signieren. - Die Signatur beweist den Besitz des privaten Schlüssels. 4. **Einreichung:** Der Browser sendet die signierte Herausforderung an den Server zurück. ``` HTTP POST /auth/dbsc/refresh HTTP/1.1 Sec-Secure-Session-Id: \ Secure-Session-Response: \ ``` 5. **Validierung:** Der Server verwendet den gespeicherten öffentlichen Schlüssel, um die Signatur zu verifizieren. - _Wenn gültig:_ Der Server weiß, dass die Anfrage vom selben physischen Gerät kommt, das die Sitzung gestartet hat. Er stellt ein _neues_ kurzlebiges access_token aus (wieder 5 Minuten gültig). - _Wenn ungültig:_ Die Anfrage wird abgelehnt. Die Sitzung wird beendet. 6. **Wiederaufnahme:** Der Browser nimmt das neue Cookie und wiederholt transparent die ursprüngliche pausierte Anfrage. Der [Nutzer erfährt keine Unterbrechung](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Implementierungsnuancen #### 4.3.1 "Lift and Shift"-Verteidigung ```mermaid graph LR subgraph "Gerät des Opfers" A[Nutzer-Sitzung
mit DBSC] B[HSM/TPM
Privater Schlüssel] C[Cookie +
Session ID] A --> B A --> C B -.->|Nicht exportierbar| X[Privater Schlüssel kann
nicht extrahiert werden] end subgraph "Angriffsszenario" D[RedLine Stealer
infiziert Gerät] D --> E[Stiehlt Cookie
& Session ID] E --> F[Exportiert an
Angreifer] end subgraph "Gerät des Angreifers" G[Importiert gestohlenes
Cookie] H[Versucht Sitzung
zu nutzen] I[Server fordert
DBSC-Erneuerung] J[Kann Challenge
nicht signieren] K[Sitzung abgelehnt] G --> H H --> I I --> J J --> K end C -.->|Gestohlen| E F --> G style D fill:#ff6b6b,color:#fff style K fill:#51cf66,color:#fff style B fill:#4c6ef5,color:#fff style X fill:#51cf66,color:#fff style J fill:#ff6b6b,color:#fff ``` Betrachten wir einen Angreifer, der den PC des Nutzers mit dem RedLine Stealer infiziert. Er stiehlt das `access_token` und die `session_id`. Er importiert diese in seinen eigenen Browser. - **Szenario A (Innerhalb von 5 Minuten):** Der Angreifer könnte für ein paar Minuten Zugriff erhalten, bis das kurzlebige Token abläuft. - **Szenario B (Nach Ablauf):** Der Browser des Angreifers (auf einem anderen Gerät) versucht, das Token zu verwenden. Der Server weist es zurück und verlangt eine Erneuerung. Der Browser des Angreifers sieht die DBSC-Header, kann die Erneuerung aber nicht durchführen, weil er nicht über den gebundenen privaten Schlüssel verfügt. Der Angriff schlägt fehl. #### 4.3.2 Umfang und Datenschutz Datenschutz ist ein zentrales Designziel von DBSC. Die [W3C-Spezifikation](https://www.w3.org/TR/dbsc/) verbietet ausdrücklich die Verwendung von globalen Identifikatoren, die Nutzer über Websites hinweg verfolgen könnten. - **Schlüssel pro Origin:** Der Browser generiert ein eindeutiges Schlüsselpaar für jede Website. google.com sieht Schlüssel A; amazon.com sieht Schlüssel B. Es gibt keine Korrelation zwischen ihnen. - **Nutzer-Löschung:** Wenn der Nutzer seine Cookies/Websitedaten löscht, löscht der Browser auch die zugehörigen DBSC-Schlüssel. Dadurch wird sichergestellt, dass DBSC nicht als "Super-Cookie" verwendet werden kann, um gelöschte Identitäten wiederzubeleben. #### 4.3.3 Überlegungen zur Serverseite Die Implementierung von DBSC erfordert, dass der Server den Status der öffentlichen Schlüssel beibehält. - **Datenbank-Schema:** Die Sitzungstabelle muss aktualisiert werden, um den `public_key` und die `last_challenge` neben der `user_id` und `session_expiry` zu speichern. - **Leistung:** Der Erneuerungsvorgang beinhaltet eine kryptografische Verifizierung (z. B. Überprüfung einer ECDSA-Signatur). Obwohl schnell, ist sie rechenintensiver als die Überprüfung eines einfachen Strings. Da Erneuerungen jedoch nur alle paar Minuten stattfinden (nicht bei jeder Anfrage), ist der Mehraufwand vernachlässigbar. ## 5. Geschäftliche und produktbezogene Auswirkungen Über die technischen Spezifikationen hinaus hat DBSC erhebliche Auswirkungen auf die Geschäftsstrategie, Produkt-Roadmaps und die Compliance-Haltung. ### 5.1 ROI reibungsloser Sicherheit Sicherheitsinitiativen werden oft als Kostenstellen oder Reibungserzeuger betrachtet. DBSC dreht dieses Narrativ um. Das folgende Diagramm veranschaulicht, wie die Gerätebindung eine Kaskade von geschäftlichen Vorteilen schafft: - **Betrugsreduktion:** Durch die Neutralisierung des Hauptvektors für Account Takeovers (ATO) können Unternehmen Millionen an Betrugsverlusten einsparen. - **Supportkosten:** Die [Kontowiederherstellung](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) ist teuer. [Den Hack von vornherein zu verhindern](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), reduziert diesen betrieblichen Aufwand direkt. - **Konversionsoptimierung:** Im [E-Commerce](https://www.corbado.com/passkeys-for-e-commerce) ist jede Anmeldeaufforderung ein potenzieller Absprungpunkt. DBSC ermöglicht aggressive "Eingeloggt bleiben"-Richtlinien, die einen sofortigen Checkout ohne Passwortabfragen ermöglichen. ### 5.2 Compliance und der "Stand der Technik" Regulatorische Rahmenbedingungen wie die [DSGVO](https://www.corbado.com/de/blog/sichere-dokumentenverarbeitung) (Datenschutz-Grundverordnung) in Europa verlangen von Organisationen, "geeignete technische und organisatorische Maßnahmen" zu ergreifen, um die Sicherheit zu gewährleisten. - **Verteidigungsfähige Sicherheit:** Wenn DBSC zum Standard wird, wird es wahrscheinlich als der "Stand der Technik" für die Sitzungsverwaltung interpretiert. Im Falle einer Sicherheitsverletzung kann der Nachweis, dass DBSC implementiert wurde, eine starke Verteidigung gegen Fahrlässigkeitsvorwürfe sein. - **Bankenstandards (PSD2):** Die [Zahlungsdiensterichtlinie](https://www.corbado.com/passkeys-for-payment) 2 (PSD2) erfordert eine "starke Kundenauthentifizierung" (SCA). Während sich [SCA](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk) auf das Login konzentriert, passt die [dynamische Verknüpfung](https://www.corbado.com/de/blog/biometrie-payer-awareness) der Sitzung mit dem Gerät perfekt zu den Zielen der Richtlinie, die [Authentifizierung](https://www.corbado.com/de/blog/komplexe-passwoerter-bald-geknackt) an bestimmte Beträge und Zahlungsempfänger zu binden. ### 5.3 Hohes vs. Moderates Vertrauensniveau (Assurance) Die [Whitepapers der FIDO-Allianz](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) heben das Konzept der "Assurance Levels" hervor. - **Moderates Assurance:** Verwendet [synchronisierte Passkeys](https://www.corbado.com/de/blog/device-bound-synced-passkeys) (wie die in [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)). Hervorragend für Verbraucher-Apps, wiederherstellbar, einfach zu bedienen. - **High Assurance:** Erfordert gerätegebundene Schlüssel. Hier glänzt DBSC. Für Unternehmensressourcen (HR-Portale, Code-Repositories) oder hochwertiges [Banking](https://www.corbado.com/de/blog/finom-passkeys-banking) kann die Organisation eine Richtlinie erzwingen, die den Zugriff _nur_ von Sitzungen erlaubt, die an ein spezifisches, verwaltetes Gerät gebunden sind. DBSC bietet den technischen Durchsetzungsmechanismus für diese Richtlinie. ## 6. DBSC im Vergleich zu Alternativen Um DBSC in vollem Umfang zu würdigen, müssen wir es mit anderen Technologien vergleichen, die versucht haben, ähnliche Probleme zu lösen. ```mermaid graph RL subgraph "Herkömmliche Cookies" TC1[Nur Bearer Token] TC2[Anfällig für Diebstahl] TC3[Lange Sitzungen = Risiko] TC1 --> TC2 TC2 --> TC3 end subgraph "Token Binding" TB1[Bindung auf TLS-Schicht] TB2[❌ Gescheitert: Komplexe Infrastruktur] TB3[Brach bei Load Balancern ab] TB1 --> TB2 TB2 --> TB3 end subgraph "DPoP" DP1[OAuth-Token-Bindung] DP2[✅ API-Schutz] DP3[Nicht für Browser-Sitzungen] DP1 --> DP2 DP2 --> DP3 end subgraph "DBSC" D1[Bindung auf HTTP-Schicht] D2[✅ Hardware-Schlüssel-Schutz] D3[✅ Funktioniert mit CDNs/LBs] D4[✅ Browser-Sitzungen] D1 --> D2 D2 --> D3 D3 --> D4 end style TC2 fill:#ff6b6b,color:#fff style TB2 fill:#ff6b6b,color:#fff style D2 fill:#51cf66,color:#fff style D3 fill:#51cf66,color:#fff style D4 fill:#51cf66,color:#fff style DP2 fill:#51cf66,color:#fff ``` ### 6.1 DBSC vs. Token Binding Wie bereits erwähnt, versuchte Token Binding, die Sitzung an die TLS-Schicht zu binden. - **Token Binding:** Erforderte Unterstützung vom Client, vom Server _und_ jedem Hop dazwischen (Load Balancer, TLS-Terminatoren). Es brach ab, wenn eine Verbindung beendet und neu verschlüsselt wurde. - **DBSC:** [Operiert auf der HTTP-Anwendungsschicht](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Es passiert Load Balancer transparent als Standard-Header/Cookies. Es ist viel einfacher in modernen Cloud-Architekturen (AWS/GCP/Azure) zu implementieren, in denen TLS oft vom Edge-Netzwerk des Cloud-Anbieters gehandhabt wird. ### 6.2 DBSC vs. DPoP (Demonstrating Proof of Possession) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) ist der Standard für "sender-constrained" OAuth-Tokens. Es bindet sowohl Access-Tokens _als auch_ Refresh-Tokens an einen öffentlichen Schlüssel – entscheidend, da Refresh-Tokens selbst langlebige Inhaber-Anmeldedaten sind. Jede API-Anfrage enthält einen DPoP-Nachweis: ein signiertes JWT mit HTTP-Methode, URL, Zeitstempel und eindeutigem Identifikator. High-Assurance-Spezifikationen wie [FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html) fordern sender-constrained Tokens; DPoP ist die empfohlene Methode, wenn mTLS nicht verfügbar ist. **Der Hauptunterschied:** DPoP-Schlüssel leben im Anwendungskontext. Best Practice ist die Verwendung von OS-APIs für nicht extrahierbaren Speicher, dies wird jedoch nicht erzwungen – viele Implementierungen bewahren Schlüssel im JavaScript-zugänglichen Speicher auf. Wenn ein Angreifer beliebigen Code ausführen kann (XSS, Malware), kann er auf DPoP-Schlüssel zugreifen oder Nachweise bei Bedarf generieren. DPoP stoppt Token-Replay _zwischen verschiedenen Clients_, kann aber einen kompromittierten Browser-Kontext nicht schützen. DBSC verlagert den Proof-of-Possession in den Browser und in die Hardware. Der private Schlüssel befindet sich in einem TPM oder [Secure Enclave](https://www.corbado.com/glossary/secure-enclave), die JavaScript weder lesen noch exportieren kann. Der Browser übernimmt das Protokoll und erstellt Signaturen, ohne Schlüssel für den Anwendungscode preiszugeben. Selbst wenn die Web-App vollständig kompromittiert ist, kann ein Angreifer keine neuen Nachweise für gestohlene Cookies auf einem anderen Rechner prägen. | Aspekt | DPoP | DBSC | | --------------------- | ------------------------------------ | ------------------------------- | | **Ziel** | OAuth Access- + Refresh-Tokens | Browser-Sitzungscookies | | **Schlüsselspeicher** | App-Kontext (Best Practice: OS-APIs) | Hardware-gestützt (TPM) | | **XSS-Resistenz** | ⚠️ Implementierungsabhängig | ✅ Schlüssel nicht exportierbar | | **Primäre Nutzung** | Native Apps, SPAs, FAPI 2.0 | Nutzerorientierte Web-Sitzungen | **Synergie:** Wie die [FIDO-Allianz anmerkt](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), eliminieren Passkeys Phishing beim Login, während DBSC/DPoP Post-Authentifizierungs-Tokens schützen. Eine moderne Architektur kombiniert beides: DPoP für OAuth-APIs (insbesondere reguliertes Open [Banking](https://www.corbado.com/de/blog/finom-passkeys-banking)), DBSC für Browser-Sitzungen. Zusammen schließen sie den "Lift and Shift"-Angriffsvektor über den gesamten Lebenszyklus der Sitzung. ### 6.3 DBSC vs. Kurzlebige Cookies (allein) Die bloße Verkürzung von Cookie-Lebensdauern (z. B. auf 15 Minuten) verbessert die Sicherheit, zerstört aber das UX. Nutzer sind gezwungen, sich ständig anzumelden. DBSC ermöglicht die _effektive_ Sicherheit eines 5-Minuten-Cookies mit der _User Experience_ eines 30-Tage-Cookies. ## 7. Shared Signals und dynamische Reaktion (CAEP/RISC) ```mermaid %%{init: { "theme": "default", "themeVariables": { "actorBkg": "#ffffff", "actorBorder": "#000000", "noteBkgColor": "#f1f3f5", "noteTextColor": "#000000", "activationBkgColor": "#e0e0e0", "actorColours": { "ST": "#ff6b6b", "IdP": "#4c6ef5" } } }}%% sequenceDiagram participant ST as Security Tools
(CrowdStrike, Defender) participant IdP as Identity Provider
(Okta, Google, Azure) participant SP1 as Service Provider 1
(Slack) participant SP2 as Service Provider 2
(Salesforce) participant SP3 as Service Provider 3
(Banking-App) participant Session as Nutzer-Sitzung
(DBSC-geschützt) Note over ST,Session: Bedrohungserkennungs-Phase ST->>ST: Erkennt Malware auf
Nutzergerät ST->>IdP: RISC-Signal:
"Gerät kompromittiert" Note over IdP,SP3: Signal-Propagations-Phase IdP->>SP1: CAEP-Event:
"Gerät kompromittiert" IdP->>SP2: CAEP-Event:
"Gerät kompromittiert" IdP->>SP3: CAEP-Event:
"Gerät kompromittiert" Note over SP1,Session: Durchsetzungs-Phase (mit DBSC) Session->>SP1: Nächster Erneuerungsversuch
(innerhalb von Minuten) SP1-->>Session: x Signatur ablehnen Session->>SP2: Nächster Erneuerungsversuch SP2-->>Session: x Signatur ablehnen Session->>SP3: Nächster Erneuerungsversuch SP3-->>Session: x Signatur ablehnen Note over Session: Sitzungen können beim nächsten Erneuerungsversuch beendet werden ``` Das Potenzial von DBSC wird verstärkt, wenn es mit dem [**Shared Signals Framework (SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) kombiniert wird, insbesondere dem **Continuous Access Evaluation Profile (CAEP)** und **Risk Management (RISC)**. Hinweis: SSF/CAEP ist eine aufstrebende Ökosystem-Fähigkeit – das Architekturmuster ist definiert, aber der herstellerübergreifende Einsatz ist noch in der Entwicklung. Im alten Modell hatte der Identity Provider (IdP) bei der Kompromittierung des Geräts eines Nutzers keine Möglichkeit, dem Service Provider (SP) mitzuteilen, die Sitzung _sofort_ zu beenden. Der SP musste warten, bis das Cookie abgelaufen war. Der vorgesehene DBSC + CAEP-Ablauf: 1. **Auslöser:** Ein Endpunkt-Sicherheits-Tool (wie CrowdStrike oder Microsoft Defender) erkennt Malware auf dem Laptop des Nutzers. 2. **Signal:** Das Sicherheits-Tool sendet ein RISC-Signal an den Identity Provider (z. B. Okta/Google). 3. **Propagation:** Der IdP pusht ein CAEP-Ereignis an verbundene Apps: "Gerät kompromittiert." 4. **Durchsetzung (DBSC):** Wenn der Browser das nächste Mal versucht, das kurzlebige DBSC-Cookie zu erneuern, weist der Server die Signatur zurück und beendet die Sitzung.\ Dieses [Architekturmuster](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) ermöglicht einen schnelleren Widerruf – die tatsächliche Latenz hängt vom Erneuerungszeitraum der Site ab und davon, ob sie sowohl DBSC als auch SSF implementiert haben. ## 8. Browser- und Ökosystem-Unterstützung Die Einführung von DBSC hängt von den Browser-Herstellern ab. Die Landschaft hat sich 2026 erheblich verschoben: Chrome hat DBSC im April 2026 von der Origin Trial in die allgemeine Verfügbarkeit auf Windows überführt, macOS folgt als Nächstes. Andere Browser evaluieren noch. ### 8.1 Google Chrome Google ist der primäre Treiber von DBSC und der erste Browser, der es breitflächig ausliefert. - **Status (April 2026):** [Chrome 146 veröffentlicht DBSC in allgemeiner Verfügbarkeit auf Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) und beendet die Origin-Trial-Phase. macOS-Unterstützung, unter Verwendung der Secure Enclave, ist für eine kommende Chrome-Version angekündigt. - **Hardware:** Windows nutzt TPM, macOS wird die Secure Enclave nutzen. Google hat erklärt, dass es auch **softwarebasierte Schlüssel** erforscht, um den DBSC-Schutz auf Geräte ohne dedizierte sichere Hardware auszudehnen. - **Roadmap:** Googles GA-Ankündigung veröffentlichte auch die nächsten Schritte der Roadmap: - **Sicherung föderierter Identitäten:** [Cross-Origin](https://www.corbado.com/blog/iframe-passkeys-webauthn)-DBSC-Bindungen, sodass die Sitzung der [Relying Party](https://www.corbado.com/glossary/relying-party) (RP) an denselben Geräteschlüssel gebunden bleibt wie die Sitzung des Identity Providers (IdP), wodurch eine ununterbrochene Vertrauenskette durch [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) gewahrt bleibt. - **Erweiterte Registrierung:** Bindung von DBSC-Sitzungen an bereits bestehendes, vertrauenswürdiges Schlüsselmaterial wie **mTLS-Zertifikate** oder **Hardware-Sicherheitsschlüssel**, anstatt beim Login einen neuen Schlüssel zu generieren. - **Breitere Geräteunterstützung:** softwarebasierte Schlüssel für Geräte ohne TPM / Secure Enclave. - **Operative Ergebnisse:** Während des Rollouts meldet Google eine "signifikante Reduzierung von Sitzungsdiebstählen" für Sitzungen, die durch DBSC geschützt sind. - **Google-Konten:** Unabhängig davon hatte Google bereits einen DBSC-ähnlichen Schutz für [Google-Konto-Cookies auf Chrome für Windows](https://support.google.com/chrome/a/answer/2657289) ausgerollt, der über Unternehmensrichtlinien gesteuert wird. Dies schützt Gmail/Workspace und ist nun dieselbe Technologiefamilie, die für das allgemeine Web GA ist. ### 8.2 Microsoft Edge & Windows Microsoft beteiligt sich aktiv. - **Status:** Edge führte eine [DBSC Origin Trial](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) unter Windows durch, die im Oktober 2025 endete. Es wurde kein Ersatztrial oder GA angekündigt. - **Unternehmenskontext:** Edge nutzt die ["Primary Refresh Token" (PRT)-Architektur](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) für Entra/Azure AD [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso), die konzeptionell DBSC ähnelt. PRT bleibt ein Microsoft-spezifischer Mechanismus; es gibt keinen angekündigten Plan, es mit dem DBSC-Webstandard für Drittanbieter-Websites zu vereinheitlichen. ### 8.3 Apple Safari (WebKit) Apples Haltung ist kritisch für die mobile Abdeckung. - **Status:** WebKit hat ein [Standards-Positions-Issue](https://github.com/WebKit/standards-positions/issues/281), das DBSC bewertet und auf Usability-/Datenschutzbedenken hinweist. Die [Safari](https://www.corbado.com/de/blog/digital-credentials-api)-Versionshinweise erwähnen DBSC nicht. Es gibt keine öffentliche Aussage "wird aktiv implementiert". - **Privacy First:** Apples Hauptsorge ist, dass DBSC für "Super-Cookies" (unlöschbares Tracking) verwendet werden könnte. Die W3C-Spezifikation geht darauf ein, indem sie sicherstellt, dass Schlüssel zusammen mit den Websitedaten gelöscht werden. - **Engagement:** WebKit beteiligt sich am Standardisierungsprozess, aber der Implementierungsstatus ist unklar – "in Diskussion" anstatt "in Entwicklung". ### 8.4 Mozilla Firefox Mozilla hat ein [Standards-Positions-Issue](https://github.com/mozilla/standards-positions/issues/912), das DBSC bewertet und auf Bedenken hinsichtlich Komplexität und Datenschutz hinweist. Es gibt keine öffentliche Verpflichtung zur Implementierung, sobald sich der Standard stabilisiert. ## 9. Empfehlungen: Nutzer heute schützen Angesichts der aktuellen Ökosystem-Unterstützung für DBSC und Passkeys sollten Organisationen einen phasenweisen Ansatz zur Implementierung dieser komplementären Technologien verfolgen. Die folgende Roadmap skizziert sofortige Maßnahmen und strategische Planungsmeilensteine: ### 9.1 Sofortige Maßnahmen (jetzt Chrome 146 GA ist) 1. **Passkeys zuerst bereitstellen**: Beginnen Sie mit der [Passkey-Implementierung](https://www.corbado.com/de/blog/warum-passkey-implementierungen-scheitern), um die Authentifizierungsschicht zu sichern. Dies bietet sofortigen Schutz vor Credential Phishing und ist die Voraussetzung, um einen echten Mehrwert aus DBSC zu ziehen. 2. **DBSC-Registrierungs- und Erneuerungsendpunkte ausliefern**: Mit Chrome 146 GA liegt die realistische Arbeit nun in der Backend-Integration: Fügen Sie `Secure-Session-Registration`-Header in Login-Antworten hinzu und implementieren Sie `/dbsc/register` sowie einen Refresh-Endpunkt, der signierte Challenges verifiziert. Der Front-End-Code muss nicht geändert werden. 3. **Kurzlebige Sitzungen mit Refresh-Tokens implementieren**: Wenn Sie noch nicht bereit für DBSC sind, übernehmen Sie das Architekturmuster von kurzlebigen Tokens mit Refresh-Mechanismen. Dies bereitet Ihr Backend auf DBSC vor und verbessert gleichzeitig die Sicherheit heute. ### 9.2 Strategische Planung (nächste 12 Monate) 1. **Hybriden Ansatz wählen**: Verwenden Sie Feature-Detection, um DBSC an fähige Browser (derzeit Chrome 146+ auf Windows, macOS Secure Enclave folgt) auszuliefern, während Fallback-Optionen beibehalten werden. Dies maximiert die Sicherheit, ohne Nutzer von [Safari](https://www.corbado.com/de/blog/digital-credentials-api), [Firefox](https://www.corbado.com/de/blog/digital-credentials-api) oder Edge auszuschließen. 2. **Vorbereitung auf die nächsten Roadmap-Punkte**: Google hat explizit föderierte Identitäten (Cross-Origin SSO-Bindungen), erweiterte Registrierung (mTLS / Hardware-Schlüssel) und softwarebasierte Schlüssel für eine breitere Geräteabdeckung angekündigt. Wenn Sie eine SSO- oder IdP-Schicht betreiben, beginnen Sie jetzt mit der Konzeption der [Cross-Origin](https://www.corbado.com/blog/iframe-passkeys-webauthn)-Bindung. 3. **Integration mit Identity Providern**: Wenn Sie Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) oder ähnliche IdPs verwenden, arbeiten Sie mit ihnen zusammen, um die DBSC-Unterstützung in deren SDKs zu aktivieren. Viele nahmen an den Origin Trials teil und liefern aktiv DBSC-Funktionen aus, nachdem Chrome nun GA ist. ### 9.3 Implementierungs-Best-Practices - **Starten Sie mit hochwertigen Zielen**: Priorisieren Sie DBSC für Admin-Panels, Finanztransaktionen und den Zugriff auf sensible Daten. - **Verwenden Sie verwaltete Lösungen**: Ziehen Sie Plattformen wie Corbado in Betracht, die die Komplexität der DBSC-Implementierung und der Browser-Kompatibilität handhaben. - **Messen und iterieren**: Verfolgen Sie Metriken wie versuchte Session-Hijackings, Support-Tickets und Nutzerreibung, um den ROI zu demonstrieren. - **Bereiten Sie sich auf Compliance vor**: Dokumentieren Sie Ihre DBSC-Implementierung, da sie wahrscheinlich eine Compliance-Anforderung für den Umgang mit sensiblen Daten werden wird. ## 10. Wie Corbado helfen kann: Brücke in die Zukunft DBSC von Grund auf neu zu implementieren, ist eine enorme ingenieurtechnische Leistung. Es erfordert kryptografische Expertise, tiefes Wissen über Browser-Inkonsistenzen und eine robuste serverseitige Infrastruktur zur Verwaltung von Schlüsseln und Challenges. Hier fungiert **Corbado** als Enabler. ### 10.1 Grundlage: Passkeys Man kann keine Sitzung mit hohem Vertrauensniveau (High Assurance) auf einem Login mit niedrigem Vertrauensniveau aufbauen. Wenn sich ein Nutzer mit einem schwachen Passwort anmeldet, ist die Sitzung nur so sicher wie dieses Passwort. Das Kernprodukt von Corbado (**Managed Passkeys**) bietet die notwendige Grundlage. Durch die Integration von Corbado können Organisationen problemlos Passkeys bereitstellen und sicherstellen, dass der Start der Sitzung [Phishing-resistent](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) ist. ### 10.2 Zukunft: DBSC zur Erkennung vertrauenswürdiger Geräte Corbado wird DBSC nutzen, um die Erkennung vertrauenswürdiger Geräte zu verbessern. Wenn DBSC-Signale verfügbar sind, liefern sie den kryptografischen Beweis, dass eine Sitzung von einem bestimmten Gerät stammt, wodurch Corbado die Authentifizierungs-Vertrauensniveaus entsprechend erhöhen kann. - **Lösung der Zweideutigkeit von synchronisierten Passkeys:** [Synchronisierte Passkeys](https://www.corbado.com/de/blog/device-bound-synced-passkeys) sind bequem, schaffen aber eine Vertrauenslücke: Wenn sich ein Nutzer mit einem synchronisierten Passkey authentifiziert, können Sie nicht erkennen, ob es sich um seinen üblichen Laptop oder um ein brandneues Gerät handelt, das die Anmeldedaten gerade erst synchronisiert hat. DBSC schließt diese Lücke. Durch die Überprüfung, ob das Gerät über eine etablierte DBSC-Bindung verfügt, kann Corbado verifizieren, dass das Gerät wirklich bekannt und vertrauenswürdig ist, und nicht nur eine erstmalige Synchronisierung darstellt. - **Höheres Vertrauen für bekannte Geräte:** Wenn DBSC-Signale bestätigen, dass ein Gerät zuvor gesehen wurde, kann Corbado sicherere Risikoentscheidungen treffen: weniger Aufforderungen zur Step-up-Authentifizierung für legitime, wiederkehrende Nutzer, strengere Prüfung von Sitzungen von unbekannten Geräten. - **Ergänzung der Passkey Intelligence:** DBSC-Signale integrieren sich in Corbados bestehende [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) Engine. Die Kombination aus Passkey-basierter Authentifizierung und DBSC-basierter Gerätebindung schafft eine vollständige Vertrauenskette vom Login über den gesamten Lebenszyklus der Sitzung. Bei Fragen dazu, wie Corbado plant, DBSC in seine Plattform zu integrieren, [wenden Sie sich an das Team](https://www.corbado.com/contact). ### 10.3 Graceful Fallback (die "hybride" Realität) In den nächsten Jahren wird das Web hybrid sein. Einige Nutzer werden DBSC-fähige Browser haben (Chrome auf [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)); andere werden auf älteren Systemen sein. Mit dieser Fragmentierung umzugehen, ist schwierig. Corbados [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) Engine ist darauf ausgelegt, genau diese Art von Fallback-Logik zu handhaben und Passkeys an fähige Geräte und Fallbacks an andere auszuliefern. Dieselbe Intelligenz gilt für die Sitzungsbindung und stellt sicher, dass die Sicherheit für jeden Nutzer gemäß den Fähigkeiten seines Geräts maximiert wird. ## 11. Fazit: Der Weg nach vorn für DBSC Die Ära des "Bearer Tokens" neigt sich dem Ende zu. Die aktuelle Sitzungsverwaltung scheitert katastrophal – Inhaber-Tokens können von industriellen Malware-Operationen gestohlen und von jedem Gerät aus verwendet werden, was Kontoübernahmen ermöglicht, die selbst die stärksten Authentifizierungsmethoden umgehen. Diese grundlegende Schwachstelle hat eine Untergrundwirtschaft im Wert von Milliarden geschaffen. [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) stellen die aufkommende Antwort der Branche dar. Im Gegensatz zu herkömmlichen sicheren Cookies mit ihren HttpOnly-Flags und statischen Geheimnissen fügt DBSC einen kryptografischen Besitznachweis durch gerätegebundene Schlüssel hinzu. Dies macht gestohlene Cookies weitaus weniger wertvoll. Sie können von einem anderen Gerät aus nicht erneuert werden. Wo Token Binding daran scheiterte, dass es komplexe Änderungen auf der TLS-Schicht über die gesamte Infrastruktur hinweg erforderte, ist DBSC erfolgreich, da es auf der HTTP-Anwendungsschicht operiert und mit vorhandenen Load Balancern und CDN-Architekturen kompatibel ist. Hinweis: DBSC verfügt über dokumentierte Fallback-Pfade, bei denen der Browser die Bindung überspringt (TPM nicht verfügbar, Netzwerkfehler), sodass es das Risiko von Cookie-Diebstahl zwar stark reduziert, aber nicht vollständig eliminiert. Die Synergie zwischen DBSC und Passkeys legt die Messlatte für Angreifer über die gesamte Nutzerreise hinweg erheblich höher. Passkeys eliminieren Credential Phishing beim Login, während DBSC das Session Hijacking durch Remote-Cookie-Diebstahl stark erschwert – zusammen bilden sie das "High Assurance"-Identitätsframework, das sich die [FIDO](https://www.corbado.com/de/blog/emv-3ds-acs-passkeys-fido-und-spc)-Allianz vorstellt. Mit der [Veröffentlichung von DBSC in GA auf Windows mit Chrome 146 im April 2026](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) und der folgenden macOS Secure Enclave-Unterstützung ist der Standard von der Vorbereitungs- in die Rollout-Phase übergegangen. Googles veröffentlichte Roadmap (föderierte Identitäten, mTLS / Hardware-Schlüssel-Registrierung, softwarebasierte Schlüssel) signalisiert die Erweiterung für die nächsten 12 Monate. Für Produktmanager ist das geschäftliche Argument überzeugend: DBSC ermöglicht "unendliche" sichere Sitzungen, die die [Login-Reibung](https://www.corbado.com/de/blog/login-reibung-zerstoert-conversion) drastisch reduzieren und gleichzeitig Betrugsverluste und Supportkosten senken. Der ROI zeigt sich in höheren Konversionsraten, weniger Passwort-Reset-Tickets und eliminierten Account-Takeover-Vorfällen. Organisationen, die OAuth verwenden, können dasselbe Schlüsselbindungs-Konzept durch DPoP für API-Tokens nutzen, während die Integration mit Shared Signals (CAEP/RISC) eine Reaktion auf Bedrohungen in Echtzeit ermöglicht – durch sofortigen Widerruf kompromittierter Sitzungen beim nächsten Erneuerungsversuch. Die Implementierung erfordert keinen kompletten Neubau. Plattformen wie [Corbado](https://www.corbado.com/features) stellen Passkey-Infrastruktur bereit und verfolgen die DBSC-Entwicklungen, um die Gerätebindung zu integrieren, sobald die Browser-Unterstützung reift. Die [W3C-Spezifikation](https://www.w3.org/TR/dbsc/) ist ein aktiver Working Draft, Chrome 146 ist auf Windows GA und wird auf macOS ausgerollt, und andere Browser evaluieren den Standard noch. Die Richtung ist klar: Organisationen, die heute mit der Einführung von Passkeys und DBSC beginnen, sind am besten für die passwortlose, Phishing-resistente Zukunft aufgestellt. Die Frage ist nicht, ob gerätegebundene Sitzungen implementiert werden sollen, sondern wie schnell Sie sie bereitstellen können, um Ihre Nutzer und Ihr Geschäft zu schützen. Die Zukunft der Websicherheit ist nicht nur authentifiziert; sie ist kryptografisch an die Geräte gebunden, denen wir vertrauen. ## Häufig gestellte Fragen ### Wie funktioniert DBSC mit CAEP und RISC, um kompromittierte Sitzungen in Echtzeit zu widerrufen? Wenn Endpunkt-Sicherheits-Tools wie CrowdStrike Malware erkennen, senden sie ein RISC-Signal an den Identity Provider, der ein CAEP-Event "Gerät kompromittiert" an verbundene Apps pusht. Beim nächsten DBSC-Erneuerungsversuch (innerhalb von Minuten) lehnen diese Apps die Sitzungssignatur ab und beenden den Zugriff. Der herstellerübergreifende Einsatz von CAEP/RISC ist noch in der Entwicklung. ### Was ist der Unterschied zwischen DBSC und DPoP beim Schutz von Webanwendungs-Sitzungen? DPoP (RFC 9449) bindet OAuth Access- und Refresh-Tokens an einen öffentlichen Schlüssel auf der Anwendungsschicht und schützt in erster Linie API-Aufrufe in nativen Apps und SPAs. DBSC bindet Browser-Sitzungscookies an hardwaregestützte TPM-Schlüssel, die JavaScript weder lesen noch exportieren kann, und schützt nutzerorientierte Sitzungen selbst dann, wenn die Web-App selbst durch XSS oder Malware kompromittiert ist. ### Warum erlaubt DBSC längere Sitzungsdauern ohne Erhöhung des Sicherheitsrisikos? Herkömmliches sicheres Design schreibt kurze Sitzungs-Timeouts vor, um den Schaden zu begrenzen, falls ein Cookie gestohlen und remote wiederverwendet wird. DBSC bindet die Erneuerungsfähigkeit an den privaten Schlüssel des Ursprungsgeräts, sodass ein gestohlenes Cookie, das von einem anderen Gerät verwendet wird, an der kryptografischen Herausforderung scheitert. Sitzungen können effektiv unendlich lang sein, da Remote-Replay-Angriffe neutralisiert werden. ### Welchen geschäftlichen ROI können Unternehmen durch die Einführung von DBSC erwarten? DBSC neutralisiert Cookie-Diebstahl als den primären Vektor für Kontoübernahmen, was Betrugsverluste und Supportkosten für die [Kontowiederherstellung](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) direkt reduziert. Sichere, lange Sitzungen eliminieren wiederholte Anmeldeaufforderungen, verbessern die Konversionsraten im [E-Commerce](https://www.corbado.com/passkeys-for-e-commerce) und reduzieren Abbrüche. Die [FIDO](https://www.corbado.com/de/blog/emv-3ds-acs-passkeys-fido-und-spc)-Allianz positioniert DBSC so, dass es die Sicherheitsmesslatte höher legt und gleichzeitig die Reibung für Nutzer senkt.