Anmeldedaten für gerätegebundene Sitzungen (Device Bound Session Credentials, DBSC) erhöhen die Sicherheit der Authentifizierung durch hardwarebasierte Sitzungssicherheit.
Einführung
Viele Websites verwenden langlebige Cookies zur Nutzerauthentifizierung, diese sind jedoch anfällig für Session Hijacking. Anmeldedaten für gerätegebundene Sitzungen (Device Bound Session Credentials, DBSC) bieten eine zusätzliche hardwaregestützte Sicherheitsebene, um dieses Risiko zu verringern. So werden Sitzungen an bestimmte Geräte gebunden.
Dieser Leitfaden richtet sich an Entwickler, die Authentifizierungsabläufe in Webanwendungen verwalten. Darin wird erläutert, wie DBSC funktioniert und wie Sie es in Ihre Website einbinden.
Funktionsweise von DBSC
Auf hoher Ebene wird durch DBSC ein kryptografisches Schlüsselpaar eingeführt, das mit dem Gerät des Nutzers verknüpft ist. Chrome generiert dieses Schlüsselpaar bei der Anmeldung und speichert den privaten Schlüssel in sicherer Hardware, z. B. einem Trusted Platform Module (TPM), sofern verfügbar. Für Sitzungen werden kurzlebige Cookies verwendet. Wenn eines dieser Cookies abläuft, weist Chrome den Besitz des privaten Schlüssels nach, bevor es aktualisiert wird. Bei diesem Vorgang wird die Sitzungskontinuität mit dem ursprünglichen Gerät verknüpft.
Wenn das Gerät eines Nutzers die sichere Speicherung von Schlüsseln nicht unterstützt, wird DBSC auf das Standardverhalten zurückgesetzt, ohne den Authentifizierungsablauf zu unterbrechen.
Implementierungsübersicht
Um DBSC in Ihre Anwendung einzubinden, müssen Sie die folgenden Änderungen vornehmen:
- Ändern Sie Ihren Anmeldevorgang so, dass er einen
Secure-Session-Registration-Header enthält. - Fügen Sie einen Endpunkt für die Sitzungsregistrierung hinzu, der:
- Verknüpft einen öffentlichen Schlüssel mit der Sitzung des Nutzers.
- Stellt die Sitzungskonfiguration bereit.
- Umstellung auf kurzlebige Cookies
- Fügen Sie einen Aktualisierungs-Endpunkt hinzu, um die Erneuerung von Cookies und die Validierung des Schlüsselbesitzes zu verarbeiten.
Bei den meisten Ihrer vorhandenen Endpunkte sind keine Änderungen erforderlich. DBSC ist so konzipiert, dass es additiv und nicht störend ist.
Wenn ein erforderliches kurzlebiges Cookie fehlt oder abgelaufen ist, pausiert Chrome die Anfrage und versucht, das Cookie zu aktualisieren. So kann Ihre App weiterhin die üblichen Sitzungscookie-Prüfungen verwenden, um zu bestätigen, dass der Nutzer angemeldet ist. Da dies typischen Authentifizierungsabläufen entspricht, sind für DBSC nur minimale Änderungen an Ihrer Anmeldelogik erforderlich.
Implementierungsschritte
In diesem Abschnitt werden die erforderlichen Änderungen an Ihrem Authentifizierungssystem beschrieben, einschließlich der Änderung Ihres Anmeldevorgangs, der Verarbeitung der Sitzungsregistrierung und der Verwaltung von Aktualisierungen kurzlebiger Cookies. Jeder Schritt ist so konzipiert, dass er sich nahtlos in Ihre bestehende Infrastruktur einfügt.
Die Implementierungsschritte folgen dem üblichen Ablauf, den ein angemeldeter Nutzer erlebt, wenn DBSC aktiv ist: Registrierung bei der Anmeldung, gefolgt von regelmäßigen kurzlebigen Cookie-Aktualisierungen. Sie können jeden Schritt unabhängig voneinander testen und implementieren, je nachdem, wie sitzungsabhängig Ihre App ist.
1. Anmeldevorgang ändern
Antworten Sie nach der Anmeldung des Nutzers mit einem langlebigen Cookie und einem Secure-Session-Registration-Header. Beispiel:
Der folgende HTTP-Antwortheader wird nach erfolgreicher Sitzungsregistrierung zurückgegeben:
HTTP/1.1 200 OK
Secure-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 die sichere Schlüsselspeicherung unterstützt, kontaktiert Chrome den /StartSession-Endpunkt mit einem öffentlichen Schlüssel in einem JSON Web Token (JWT).
auth_cookie steht in diesem Beispiel für Ihr Sitzungstoken. Sie können dieses Cookie beliebig benennen, solange der Name mit dem Feld name in Ihrer Sitzungskonfiguration übereinstimmt und in Ihrer gesamten Anwendung einheitlich verwendet wird.
2. Endpunkt für die Sitzungsregistrierung implementieren
Unter /StartSession sollte Ihr Server Folgendes tun:
- Ordnen Sie den empfangenen öffentlichen Schlüssel der Sitzung des Nutzers zu.
- Mit einer Sitzungskonfiguration antworten
- 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 Prozess 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-Secure-Session-Id: session_idIhr Server antwortet mit einer Challenge:
HTTP/1.1 403 Forbidden Secure-Session-Challenge: "challenge_value"Chrome signiert die Challenge mit dem gespeicherten privaten Schlüssel und wiederholt die Anfrage:
POST /RefreshEndpoint HTTP/1.1 Sec-Secure-Session-Id: session_id Secure-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.
Alternatives Integrationsmuster
Um die Stabilität zu verbessern, können Websites neben dem kurzlebigen Cookie ein zweites Cookie ohne DBSC hinzufügen. Dieses langlebige Cookie wird nur zum Ausstellen neuer kurzlebiger Tokens verwendet und hilft, zwischen wirklich nicht authentifizierten Anfragen und vorübergehenden DBSC-Fehlern zu unterscheiden.
- Das langlebige Cookie bleibt auch dann bestehen, wenn DBSC fehlschlägt.
- Das kurzlebige Cookie wird mit DBSC aktualisiert und ist für vertrauliche Vorgänge erforderlich.
Mit diesem Muster haben Websites mehr Kontrolle darüber, wie sie Grenzfälle behandeln.
Warnhinweise und Fallback-Verhalten
In den folgenden Fällen kann es sein, dass Chrome DBSC-Vorgänge überspringt und Anfragen ohne das von DBSC verwaltete kurzlebige Cookie sendet:
- Der Aktualisierungsendpunkt ist aufgrund von Netzwerkfehlern oder Serverproblemen nicht erreichbar.
- Das TPM ist beschäftigt oder es treten Signierungsfehler auf. Da das TPM von Systemprozessen gemeinsam genutzt wird, können durch zu viele Aktualisierungen die Ratenbegrenzungen überschritten werden.
- Das von DBSC verwaltete kurzlebige Cookie ist ein Drittanbieter-Cookie und der Nutzer hat Drittanbieter-Cookies in seinen Browsereinstellungen blockiert.
In diesen Fällen greift Chrome auf das langlebige Cookie zurück, sofern es noch vorhanden ist. Dieser Fallback funktioniert nur, wenn Ihre Implementierung sowohl ein langlebiges als auch ein kurzlebiges Cookie enthält. Ist das nicht der Fall, sendet Chrome die Anfrage ohne Cookie.
Zusammenfassung
Anmeldedaten für gerätegebundene Sitzungen verbessern die Sitzungssicherheit mit minimalen Änderungen an Ihrer Anwendung. Sie bieten einen besseren Schutz vor Session-Hijacking, da Sitzungen an bestimmte Geräte gebunden werden. Die meisten Nutzer profitieren davon, ohne dass es zu Unterbrechungen kommt. DBSC wird auf nicht unterstützter Hardware auf elegante Weise deaktiviert.
Weitere Informationen finden Sie in der DBSC-Spezifikation.