Anmeldedaten für gerätegebundene Sitzungen (Device Bound Session Credentials, DBSC) erhöhen die Authentifizierung durch hardwaregestützte Sitzungssicherheit.
Einführung
Viele Websites verwenden für die Nutzerauthentifizierung langlebige Cookies, die jedoch anfällig für Session-Hijacking sind. Mit Anmeldedaten für gerätegebundene Sitzungen (Device Bound Session Credentials, DBSC) wird eine zusätzliche hardwaregestützte Sicherheitsebene hinzugefügt, um dieses Risiko zu minimieren und dafür zu sorgen, dass Sitzungen an bestimmte Geräte gebunden sind.
Dieser Leitfaden richtet sich an Entwickler, die Authentifizierungsabläufe in Webanwendungen verwalten. Dort wird erläutert, wie DBSC funktioniert und wie Sie es in Ihre Website einbinden.
Funktionsweise von DBSC
Im Groben führt DBSC ein kryptografisches Schlüsselpaar ein, das mit dem Gerät des Nutzers verknüpft ist. Chrome generiert dieses Schlüsselpaar während der Anmeldung und speichert den privaten Schlüssel auf sicherer Hardware, z. B. auf einem Trusted Platform Module (TPM), sofern verfügbar. Für Sitzungen werden kurzlebige Cookies verwendet. Wenn eines dieser Cookies abläuft, bestätigt Chrome den Besitz des privaten Schlüssels, bevor es aktualisiert wird. Dabei wird die Sitzungskontinuität mit dem ursprünglichen Gerät verknüpft.
Wenn das Gerät eines Nutzers den sicheren Schlüsselspeicher nicht unterstützt, wechselt DBSC reibungslos zum Standardverhalten, ohne den Authentifizierungsablauf zu unterbrechen.
Implementierungsübersicht
Wenn Sie DBSC in Ihre Anwendung einbinden möchten, müssen Sie die folgenden Änderungen vornehmen:
- Ändern Sie den Anmeldevorgang so, dass er eine
Sec-Session-Registration-Überschrift enthält. - Fügen Sie einen Endpunkt für die Sitzungsregistrierung hinzu, der folgende Anforderungen erfüllt:
- Verknüpft einen öffentlichen Schlüssel mit der Sitzung des Nutzers.
- Stellt die Sitzungskonfiguration bereit.
- Umstellung auf kurzlebige Cookies
- Fügen Sie einen Aktualisierungsendpunkt hinzu, um die Cookie-Verlängerung und die Schlüsselinhaberprüfung zu verarbeiten.
An den meisten vorhandenen Endpunkten sind keine Änderungen erforderlich. DBSC soll ergänzend und störungsfrei sein.
Wenn ein erforderliches kurzlebiges Cookie fehlt oder abgelaufen ist, hält Chrome die Anfrage an und versucht, das Cookie zu aktualisieren. So kann Ihre App weiterhin die üblichen Prüfungen für Sitzungscookies verwenden, um zu bestätigen, dass der Nutzer angemeldet ist. Da dies den üblichen Authentifizierungsabläufen entspricht, erfordert DBSC nur minimale Änderungen an Ihrer Anmeldelogik.
Implementierungsschritte
In diesem Abschnitt werden die erforderlichen Änderungen an Ihrem Authentifizierungssystem beschrieben, einschließlich der Änderung des Anmeldevorgangs, der Verwaltung der Sitzungsregistrierung und der Verwaltung kurzlebiger Cookie-Aktualisierungen. Jeder Schritt ist so konzipiert, dass er sich nahtlos in Ihre vorhandene Infrastruktur einbinden lässt.
Die Implementierungsschritte folgen dem üblichen Ablauf, der für einen angemeldeten Nutzer gilt, wenn DBSC aktiv ist: Registrierung bei der Anmeldung, gefolgt von regelmäßigen Aktualisierungen kurzlebiger Cookies. Je nach Sitzungssensitivität Ihrer App können Sie die einzelnen Schritte unabhängig voneinander testen und implementieren.
1. Anmeldevorgang ändern
Nachdem sich der Nutzer angemeldet hat, antworte mit einem langlebigen Cookie und einem Sec-Session-Registration-Header. Beispiel:
Nach erfolgreicher Sitzungsregistrierung wird der folgende HTTP-Antwortheader zurückgegeben:
HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax
Wenn das Gerät den sicheren Schlüsselspeicher unterstützt, kontaktiert Chrome den /StartSession-Endpunkt mit einem öffentlichen Schlüssel in einem JSON Web Token (JWT).
Das auth_cookie in diesem Beispiel steht für dein Sitzungstoken. Sie können diesem Cookie einen beliebigen Namen geben, solange er mit dem Feld name in Ihrer Sitzungskonfiguration übereinstimmt und in Ihrer Anwendung einheitlich verwendet wird.
2. Endpunkt für die Sitzungsregistrierung implementieren
Bei /StartSession sollte Ihr Server Folgendes tun:
- Verknüpfen Sie den empfangenen öffentlichen Schlüssel mit der Sitzung des Nutzers.
- Antworte mit einer Sitzungskonfiguration.
- Ersetzen Sie das langlebige Cookie durch ein kurzlebiges.
Im folgenden Beispiel ist das kurzlebige Cookie so konfiguriert, dass es nach 10 Minuten abläuft:
HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutes Set-Cookie: Domain=example.com; Secure; SameSite=Lax
{
"session_identifier": "session_id",
"refresh_url": "/RefreshEndpoint",
"scope": {
"origin": "https://example.com",
"include_site": true,
"scope_specification": [
{ "type": "exclude", "domain": "*.example.com", "path": "/static" }
]
},
"credentials": [{
"type": "cookie",
"name": "auth_cookie",
"attributes": "Domain=example.com; Secure; SameSite=Lax"
}]
}
3. Aktualisierungsendpunkt implementieren
Wenn das kurzlebige Cookie abläuft, startet Chrome einen Aktualisierungsvorgang, um den Besitz des privaten Schlüssels nachzuweisen. Dieser Vorgang umfasst koordinierte Aktionen von Chrome und Ihrem Server:
Chrome leitet die Anfrage des Nutzers an Ihre Anwendung weiter und sendet eine Aktualisierungsanfrage an
/RefreshEndpoint:POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_idDer Server antwortet mit einer Bestätigungsforderung:
HTTP/1.1 401 Unauthorized Sec-Session-Challenge: "challenge_value"Chrome signiert die Herausforderung mit dem gespeicherten privaten Schlüssel und versucht die Anfrage noch einmal:
POST /RefreshEndpoint HTTP/1.1 Sec-Session-Id: session_id Sec-Session-Response: <JWT proof>Ihr Server validiert den signierten Nachweis und stellt ein aktualisiertes kurzlebiges Cookie aus:
HTTP/1.1 200 OK Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=LaxChrome empfängt das aktualisierte Cookie und setzt die ursprüngliche verzögerte Anfrage fort.
Alternative Integrationsmuster
Um die Resilienz zu verbessern, können Websites neben dem kurzlebigen Cookie ein zweites Cookie hinzufügen, das nicht zu den dynamischen Sitzungskontroll-Cookies gehört. Dieses langlebige Cookie wird nur zum Ausstellen neuer kurzlebiger Tokens verwendet und hilft, zwischen nicht authentifizierten Anfragen und vorübergehenden DBSC-Fehlern zu unterscheiden.
- Das langlebige Cookie bleibt auch dann erhalten, wenn die DBSC fehlschlägt.
- Das kurzlebige Cookie wird mit DBSC aktualisiert und ist für sensible Vorgänge erforderlich.
Mit diesem Muster haben Websites mehr Kontrolle darüber, wie Grenzfälle behandelt werden.
Einschränkungen und Fallback-Verhalten
In den folgenden Fällen überspringt Chrome möglicherweise DBSC-Vorgänge und sendet Anfragen ohne das von DBSC verwaltete kurzlebige Cookie:
- Der Aktualisierungsendpunkt ist aufgrund von Netzwerk- oder Serverproblemen nicht erreichbar.
- Der TPM ist belegt oder es treten Signaturfehler auf. Da das TPM von mehreren Systemprozessen gemeinsam genutzt wird, können übermäßige Aktualisierungen die Ratenlimits überschreiten.
- Das von der DBSC verwaltete kurzlebige Cookie ist ein Drittanbieter-Cookie und der Nutzer hat Drittanbieter-Cookies in seinen Browsereinstellungen blockiert.
In diesen Fällen verwendet Chrome das langlebige Cookie, falls noch eines vorhanden ist. Dieser Fallback funktioniert nur, wenn Ihre Implementierung sowohl ein langlebiges als auch ein kurzlebiges Cookie enthält. Ist dies nicht der Fall, sendet Chrome die Anfrage ohne Cookie.
Zusammenfassung
Mit Anmeldedaten für gerätegebundene Sitzungen lässt sich die Sitzungssicherheit mit minimalen Änderungen an Ihrer Anwendung verbessern. Sie bieten einen besseren Schutz vor Session-Hijacking, da Sitzungen an bestimmte Geräte gebunden werden. Die meisten Nutzer profitieren davon, ohne Unterbrechungen zu erleben, und DBSC wechselt bei Bedarf nahtlos zu nicht unterstützter Hardware.
Weitere Informationen finden Sie in der DBSC-Spezifikation.