Apparaatgebonden sessiereferenties (DBSC)

Device Bound Session Credentials (DBSC) versterken authenticatie door hardwarematige sessiebeveiliging toe te voegen.

Daniel Rubery

José Luis Zapata

Invoering

Veel websites vertrouwen op cookies met een lange levensduur voor gebruikersauthenticatie, maar deze zijn gevoelig voor sessiekaping. Device Bound Session Credentials (DBSC) voegt een hardwarematige beveiligingslaag toe om dit risico te beperken en zorgt ervoor dat sessies aan specifieke apparaten worden gekoppeld.

Deze handleiding is bedoeld voor ontwikkelaars die authenticatiestromen in webapplicaties beheren. Het legt uit hoe DBSC werkt en hoe u het in uw site kunt integreren.

Hoe DBSC werkt

Op een hoog niveau introduceert DBSC een cryptografisch sleutelpaar dat gekoppeld is aan het apparaat van de gebruiker. Chrome genereert dit sleutelpaar tijdens het inloggen en slaat de privésleutel op in beveiligde hardware, zoals een Trusted Platform Module (TPM) , indien beschikbaar. Sessies gebruiken cookies met een korte levensduur. Wanneer een van deze cookies verloopt, bewijst Chrome het bezit van de privésleutel voordat deze wordt vernieuwd. Dit proces koppelt de sessiecontinuïteit aan het oorspronkelijke apparaat.

Als het apparaat van een gebruiker geen veilige sleutelopslag ondersteunt, valt DBSC terug op de standaardwerking zonder de authenticatiestroom te verstoren.

Implementatieoverzicht

Om DBSC in uw applicatie te integreren, moet u de volgende wijzigingen doorvoeren:

• Wijzig uw inlogstroom door een Secure-Session-Registration header toe te voegen.
• Voeg een sessieregistratie-eindpunt toe dat:
  • Koppelt een openbare sleutel aan de sessie van de gebruiker.
  • Dient voor sessieconfiguratie.
  • Overgang naar kortlevende koekjes.
• Voeg een vernieuwingseindpunt toe om het vernieuwen van cookies en het valideren van sleutelbezit af te handelen.

De meeste van uw bestaande eindpunten hoeven niet te worden gewijzigd. DBSC is ontworpen om additief en niet-verstorend te zijn.

Wanneer een vereiste kortdurende cookie ontbreekt of is verlopen, pauzeert Chrome de aanvraag en probeert deze te vernieuwen. Hierdoor kan uw app de gebruikelijke sessiecookiecontroles blijven gebruiken om te bevestigen dat de gebruiker is aangemeld. Omdat dit overeenkomt met typische authenticatieprocessen, werkt DBSC met minimale wijzigingen in uw aanmeldingslogica.

Implementatiestappen

In dit gedeelte worden de noodzakelijke wijzigingen in uw authenticatiesysteem besproken, inclusief hoe u uw inlogproces kunt aanpassen, sessieregistratie kunt verwerken en kortstondige cookievernieuwingen kunt beheren. Elke stap is ontworpen om naadloos te integreren met uw bestaande infrastructuur.

De implementatiestappen volgen de gebruikelijke workflow die een aangemelde gebruiker zou ervaren wanneer DBSC actief is: registratie bij het inloggen, gevolgd door regelmatige, kortdurende cookievernieuwingen. U kunt elke stap onafhankelijk testen en implementeren, afhankelijk van de sessiegevoeligheid van uw app.

1. Wijzig de inlogstroom

Nadat de gebruiker is ingelogd, reageert u met een langdurige cookie en een Secure-Session-Registration header. Bijvoorbeeld:

De volgende HTTP-responsheader wordt geretourneerd na succesvolle sessieregistratie:

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

Als het apparaat veilige sleutelopslag ondersteunt, maakt Chrome contact met het /StartSession eindpunt met een openbare sleutel in een JSON Web Token (JWT).

De auth_cookie in dit voorbeeld vertegenwoordigt uw sessietoken. U kunt deze cookie een willekeurige naam geven, zolang deze maar overeenkomt met het veld name in uw sessieconfiguratie en consistent wordt gebruikt in uw applicatie.

2. Implementeer het sessieregistratie-eindpunt

Bij /StartSession zou uw server het volgende moeten doen:

• Koppel de ontvangen openbare sleutel aan de sessie van de gebruiker.
• Reageer met een sessieconfiguratie.
• Vervang het langlevende koekje door een kortlevend koekje.

In het volgende voorbeeld is de kortlevende cookie zo geconfigureerd dat deze na 10 minuten verloopt:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-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. Implementeer het vernieuwingseindpunt

Wanneer de kortdurende cookie verloopt, start Chrome een vernieuwingsstroom om te bewijzen dat de persoonlijke sleutel in bezit is. Dit proces vereist gecoördineerde acties van zowel Chrome als uw server:

1. Chrome stelt het verzoek van de gebruiker uit naar uw applicatie en stuurt een vernieuwingsverzoek naar /RefreshEndpoint :

   POST /RefreshEndpoint HTTP/1.1
   Sec-Secure-Session-Id: session_id
   

2. Uw server reageert met een uitdaging:

   HTTP/1.1 403 Forbidden
   Secure-Session-Challenge: "challenge_value"
   

3. Chrome ondertekent de uitdaging met de opgeslagen persoonlijke sleutel en probeert de aanvraag opnieuw uit te voeren:

   POST /RefreshEndpoint HTTP/1.1
   Sec-Secure-Session-Id: session_id
   Secure-Session-Response: <JWT proof>
   

4. Uw server valideert het ondertekende bewijs en geeft een vernieuwde, kortstondige cookie uit:

   HTTP/1.1 200 OK
   
   Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax
   

5. Chrome ontvangt de vernieuwde cookie en hervat het oorspronkelijke uitgestelde verzoek.

Alternatief integratiepatroon

Om de veerkracht te verbeteren, kunnen sites een tweede, niet-DBSC-cookie toevoegen naast de kortdurende cookie. Deze langdurende cookie wordt alleen gebruikt om nieuwe, kortdurende tokens uit te geven en helpt onderscheid te maken tussen daadwerkelijk niet-geverifieerde verzoeken en tijdelijke DBSC-storingen.

• De cookie met een lange levensduur blijft aanwezig, ook als DBSC mislukt.
• De kortstondige cookie wordt vernieuwd met behulp van DBSC en is vereist voor gevoelige bewerkingen.

Met dit patroon hebben sites meer controle over hoe ze met randgevallen omgaan.

Waarschuwingen en terugvalgedrag

Chrome kan DBSC-bewerkingen overslaan en verzoeken verzenden zonder de door DBSC beheerde kortdurende cookie in de volgende scenario's:

• Het vernieuwingseindpunt is onbereikbaar vanwege netwerkfouten of serverproblemen.
• De TPM is bezet of ondervindt ondertekeningsfouten. Omdat de TPM over systeemprocessen wordt gedeeld, kunnen overmatige vernieuwingen de snelheidslimieten overschrijden.
• De door de DBSC beheerde kortdurende cookie is een cookie van derden. De gebruiker heeft cookies van derden geblokkeerd in de instellingen van zijn browser.

In deze situaties valt Chrome terug op het gebruik van de long-lived cookie, indien deze nog aanwezig is. Deze terugval werkt alleen als uw implementatie zowel een long-lived als een short-lived cookie bevat. Zo niet, dan verstuurt Chrome het verzoek zonder cookie.

Samenvatting

Apparaatgebonden sessiereferenties verbeteren de sessiebeveiliging met minimale wijzigingen in uw applicatie. Ze bieden sterkere bescherming tegen sessiehijacking door sessies aan specifieke apparaten te koppelen. De meeste gebruikers profiteren ervan zonder enige verstoring, en DBSC werkt soepel op niet-ondersteunde hardware.

Raadpleeg de DBSC-specificatie voor meer informatie.