Origin-proefversie: apparaatgebonden sessiereferenties in Chrome

José Luis Zapata

Device Bound Session Credentials (DBSC) is een nieuwe webfunctie die is ontworpen om gebruikerssessies te beschermen tegen cookiediefstal en sessiekaping. Deze functie kan nu worden getest als Origin-proefversie in Chrome 135.

Achtergrond

Cookies spelen een cruciale rol in moderne webauthenticatie, waardoor gebruikers ingelogd kunnen blijven tijdens browsersessies. Aanvallers maken echter steeds vaker misbruik van gestolen authenticatiecookies om sessies te kapen, waarbij multi-factor authenticatie en andere beveiligingsmechanismen voor inloggen worden omzeild.

Malware-exploitanten exfiltreren vaak sessiecookies van aangetaste apparaten, waardoor ongeautoriseerde toegang tot gebruikersaccounts mogelijk wordt. Omdat cookies dragertokens zijn, verlenen ze toegang zonder dat er een bewijs van bezit nodig is, waardoor ze een lucratief doelwit zijn voor aanvallers.

Device Bound Session Credentials (DBSC) heeft tot doel de diefstal van cookies te verstoren door een geverifieerde sessie te creëren die aan een apparaat is gekoppeld. Deze aanpak verkleint de kans dat geëxfiltreerde cookies toegang krijgen tot accounts vanaf een ander apparaat.

Hoe het werkt

DBSC introduceert een nieuwe API waarmee servers een geverifieerde sessie kunnen creëren die aan een apparaat is gekoppeld. Wanneer een sessie wordt gestart, genereert de browser een publiek-privaat sleutelpaar, waarbij de privésleutel veilig wordt opgeslagen met behulp van door hardware ondersteunde opslag zoals een Trusted Platform Module (TPM), indien beschikbaar.

De browser geeft dan een reguliere sessiecookie uit. Tijdens de levensduur van de sessie bewijst de browser periodiek het bezit van de privésleutel en vernieuwt hij de sessiecookie. De levensduur van de cookie kan kort genoeg worden ingesteld, zodat het stelen van de cookie geen voordeel oplevert voor aanvallers.

Belangrijkste componenten

  • Sessie registratie :

    • Wanneer een gebruiker inlogt, vraagt ​​de server een apparaatgebonden sessie aan met behulp van de Sec-Session-Registration HTTP-header.
    • De browser genereert een nieuw sleutelpaar en slaat de privésleutel veilig op.
    • Er wordt ook een kortstondige authenticatiecookie ingesteld en aan dit sleutelpaar gekoppeld.
    • De server koppelt de sessie aan de bijbehorende publieke sleutel, zodat de sessie alleen op het originele apparaat kan worden gebruikt.

  • Sessie vernieuwen en bewijs van bezit :

    • Wanneer de kortstondige cookie verloopt, activeert Chrome een sessievernieuwing.
    • De browser stuurt een verzoek naar een door de server gedefinieerd vernieuwingseindpunt (verstrekt tijdens de sessieregistratie) en, als de server er een aanbiedt, een ondertekende uitdaging met behulp van de Sec-Session-Challenge header.
    • De server verifieert het bewijs van bezit door het antwoord te valideren dat is ondertekend met de privésleutel van de sessie.
    • Indien geldig, geeft de server een nieuwe kortstondige cookie uit, waardoor de sessie kan worden voortgezet.

Een voordeel van deze aanpak is dat Chrome verzoeken uitstelt die anders de vernieuwde kortstondige cookie zouden missen. Dit gedrag zorgt ervoor dat sessiegebonden cookies gedurende de hele sessie consistent beschikbaar zijn en stelt ontwikkelaars in staat er met meer vertrouwen op te vertrouwen dan bij benaderingen waarbij cookies kunnen verlopen of verdwijnen zonder automatische verlenging.

Voorbeeld implementatie

Een server kan als volgt een apparaatgebonden sessie aanvragen:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256);path="/refresh";challenge="12345"

Wanneer de sessie actief is, kan de server deze verifiëren met een challenge-response-uitwisseling:

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "verify-session"

De browser reageert met:

POST /refresh
Sec-Session-Response: "signed-proof"

Voordelen

  • Vermindert diefstal van cookies : zelfs als sessiecookies worden gestolen, kunnen ze niet vanaf een ander apparaat worden gebruikt.
  • Verbetert de beveiliging zonder grote UX-wijzigingen : Werkt transparant op de achtergrond zonder dat extra gebruikersinteractie nodig is.
  • Vermindert de afhankelijkheid van cookies met een lange levensduur : Cookies met een korte levensduur worden automatisch vernieuwd zolang de sessie geldig blijft op het oorspronkelijke apparaat.
  • Ondersteunt standaard cryptografische mechanismen : maakt gebruik van door TPM ondersteunde veilige opslag, indien beschikbaar, en biedt krachtige bescherming tegen exfiltratie.

Privacy- en veiligheidsoverwegingen

DBSC is ontworpen om de beveiliging te verbeteren en tegelijkertijd de privacy van gebruikers te behouden:

  • Geen extra trackingvectoren : elke sessie is gekoppeld aan een uniek sleutelpaar, waardoor tracking tussen sessies wordt voorkomen.
  • Geen langdurige apparaatvingerafdrukken : Servers kunnen geen verschillende sessies op hetzelfde apparaat correleren, tenzij dit expliciet wordt toegestaan ​​door de gebruiker.
  • Wisbaar door gebruikers : sessies en sleutels worden verwijderd wanneer de gebruiker sitegegevens wist.
  • In lijn met het cookiebeleid : DBSC volgt dezelfde sitegebaseerde scoping als cookies en zorgt ervoor dat er geen cross-origin datalekken ontstaan.

Probeer het eens

De Device Bound Session Credentials Origin-proefversie is beschikbaar vanaf Chrome 135.

Voor lokale testen

DBSC lokaal testen:

  • Ga naar chrome://flags#device-bound-session-credentials en schakel de functie in.

Voor openbare testen

DBSC testen met de origin-proefversie in een openbare omgeving:

  1. Ga naar de Chrome Origin-proefversiepagina en meld u aan.

  2. Voeg het opgegeven token toe aan de HTTP-headers van uw site:

    Origin-Trial: <your-trial-token>

Bronnen

Doe mee en geef vorm aan de toekomst van webbeveiliging

Help ons mee om webauthenticatie veiliger te maken! We moedigen webontwikkelaars aan om DBSC te testen, in hun applicaties te integreren en feedback te delen. U kunt met ons communiceren op GitHub of deelnemen aan discussies met de Web Application Security Working Group.

Door DBSC te implementeren, kunnen we gezamenlijk de risico's van sessiekaping verminderen en de authenticatiebeveiliging voor gebruikers verbeteren. Ga vandaag nog aan de slag en help mee de toekomst van webbeveiliging te definiëren!

,

José Luis Zapata

Device Bound Session Credentials (DBSC) is een nieuwe webfunctie die is ontworpen om gebruikerssessies te beschermen tegen cookiediefstal en sessiekaping. Deze functie kan nu worden getest als Origin-proefversie in Chrome 135.

Achtergrond

Cookies spelen een cruciale rol in moderne webauthenticatie, waardoor gebruikers ingelogd kunnen blijven tijdens browsersessies. Aanvallers maken echter steeds vaker misbruik van gestolen authenticatiecookies om sessies te kapen, waarbij multi-factor authenticatie en andere beveiligingsmechanismen voor inloggen worden omzeild.

Malware-exploitanten exfiltreren vaak sessiecookies van aangetaste apparaten, waardoor ongeautoriseerde toegang tot gebruikersaccounts mogelijk wordt. Omdat cookies dragertokens zijn, verlenen ze toegang zonder dat er een bewijs van bezit nodig is, waardoor ze een lucratief doelwit zijn voor aanvallers.

Device Bound Session Credentials (DBSC) heeft tot doel de diefstal van cookies te verstoren door een geverifieerde sessie te creëren die aan een apparaat is gekoppeld. Deze aanpak verkleint de kans dat geëxfiltreerde cookies toegang krijgen tot accounts vanaf een ander apparaat.

Hoe het werkt

DBSC introduceert een nieuwe API waarmee servers een geverifieerde sessie kunnen creëren die aan een apparaat is gekoppeld. Wanneer een sessie wordt gestart, genereert de browser een publiek-privaat sleutelpaar, waarbij de privésleutel veilig wordt opgeslagen met behulp van door hardware ondersteunde opslag zoals een Trusted Platform Module (TPM), indien beschikbaar.

De browser geeft dan een reguliere sessiecookie uit. Tijdens de levensduur van de sessie bewijst de browser periodiek het bezit van de privésleutel en vernieuwt hij de sessiecookie. De levensduur van de cookie kan kort genoeg worden ingesteld, zodat het stelen van de cookie geen voordeel oplevert voor aanvallers.

Belangrijkste componenten

  • Sessie registratie :

    • Wanneer een gebruiker inlogt, vraagt ​​de server een apparaatgebonden sessie aan met behulp van de Sec-Session-Registration HTTP-header.
    • De browser genereert een nieuw sleutelpaar en slaat de privésleutel veilig op.
    • Er wordt ook een kortstondige authenticatiecookie ingesteld en aan dit sleutelpaar gekoppeld.
    • De server koppelt de sessie aan de bijbehorende publieke sleutel, zodat de sessie alleen op het originele apparaat kan worden gebruikt.

  • Sessie vernieuwen en bewijs van bezit :

    • Wanneer de kortstondige cookie verloopt, activeert Chrome een sessievernieuwing.
    • De browser stuurt een verzoek naar een door de server gedefinieerd vernieuwingseindpunt (verstrekt tijdens de sessieregistratie) en, als de server er een aanbiedt, een ondertekende uitdaging met behulp van de Sec-Session-Challenge header.
    • De server verifieert het bewijs van bezit door het antwoord te valideren dat is ondertekend met de privésleutel van de sessie.
    • Indien geldig, geeft de server een nieuwe kortstondige cookie uit, waardoor de sessie kan worden voortgezet.

Een voordeel van deze aanpak is dat Chrome verzoeken uitstelt die anders de vernieuwde kortstondige cookie zouden missen. Dit gedrag zorgt ervoor dat sessiegebonden cookies gedurende de hele sessie consistent beschikbaar zijn en stelt ontwikkelaars in staat er met meer vertrouwen op te vertrouwen dan bij benaderingen waarbij cookies kunnen verlopen of verdwijnen zonder automatische verlenging.

Voorbeeld implementatie

Een server kan als volgt een apparaatgebonden sessie aanvragen:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256);path="/refresh";challenge="12345"

Wanneer de sessie actief is, kan de server deze verifiëren met een challenge-response-uitwisseling:

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "verify-session"

De browser reageert met:

POST /refresh
Sec-Session-Response: "signed-proof"

Voordelen

  • Vermindert diefstal van cookies : zelfs als sessiecookies worden gestolen, kunnen ze niet vanaf een ander apparaat worden gebruikt.
  • Verbetert de beveiliging zonder grote UX-wijzigingen : Werkt transparant op de achtergrond zonder dat extra gebruikersinteractie nodig is.
  • Vermindert de afhankelijkheid van cookies met een lange levensduur : Cookies met een korte levensduur worden automatisch vernieuwd zolang de sessie geldig blijft op het oorspronkelijke apparaat.
  • Ondersteunt standaard cryptografische mechanismen : maakt gebruik van door TPM ondersteunde veilige opslag, indien beschikbaar, en biedt krachtige bescherming tegen exfiltratie.

Privacy- en veiligheidsoverwegingen

DBSC is ontworpen om de beveiliging te verbeteren en tegelijkertijd de privacy van gebruikers te behouden:

  • Geen extra trackingvectoren : elke sessie is gekoppeld aan een uniek sleutelpaar, waardoor tracking tussen sessies wordt voorkomen.
  • Geen langdurige apparaatvingerafdrukken : Servers kunnen geen verschillende sessies op hetzelfde apparaat correleren, tenzij dit expliciet wordt toegestaan ​​door de gebruiker.
  • Wisbaar door gebruikers : sessies en sleutels worden verwijderd wanneer de gebruiker sitegegevens wist.
  • In lijn met het cookiebeleid : DBSC volgt dezelfde sitegebaseerde scoping als cookies en zorgt ervoor dat er geen cross-origin datalekken ontstaan.

Probeer het eens

De Device Bound Session Credentials Origin-proefversie is beschikbaar vanaf Chrome 135.

Voor lokale testen

DBSC lokaal testen:

  • Ga naar chrome://flags#device-bound-session-credentials en schakel de functie in.

Voor openbare tests

DBSC testen met de origin-proefversie in een openbare omgeving:

  1. Ga naar de Chrome Origin-proefversiepagina en meld u aan.

  2. Voeg het opgegeven token toe aan de HTTP-headers van uw site:

    Origin-Trial: <your-trial-token>

Bronnen

Doe mee en geef vorm aan de toekomst van webbeveiliging

Help ons mee om webauthenticatie veiliger te maken! We moedigen webontwikkelaars aan om DBSC te testen, in hun applicaties te integreren en feedback te delen. U kunt met ons communiceren op GitHub of deelnemen aan discussies met de Web Application Security Working Group.

Door DBSC te implementeren, kunnen we gezamenlijk de risico's van sessiekaping verminderen en de authenticatiebeveiliging voor gebruikers verbeteren. Ga vandaag nog aan de slag en help mee de toekomst van webbeveiliging te definiëren!

,

José Luis Zapata

Device Bound Session Credentials (DBSC) is een nieuwe webfunctie die is ontworpen om gebruikerssessies te beschermen tegen cookiediefstal en sessiekaping. Deze functie kan nu worden getest als Origin-proefversie in Chrome 135.

Achtergrond

Cookies spelen een cruciale rol in moderne webauthenticatie, waardoor gebruikers ingelogd kunnen blijven tijdens browsersessies. Aanvallers maken echter steeds vaker misbruik van gestolen authenticatiecookies om sessies te kapen, waarbij multi-factor authenticatie en andere beveiligingsmechanismen voor inloggen worden omzeild.

Malware-exploitanten exfiltreren vaak sessiecookies van aangetaste apparaten, waardoor ongeautoriseerde toegang tot gebruikersaccounts mogelijk wordt. Omdat cookies dragertokens zijn, verlenen ze toegang zonder dat er een bewijs van bezit nodig is, waardoor ze een lucratief doelwit zijn voor aanvallers.

Device Bound Session Credentials (DBSC) heeft tot doel de diefstal van cookies te verstoren door een geverifieerde sessie te creëren die aan een apparaat is gekoppeld. Deze aanpak verkleint de kans dat geëxfiltreerde cookies toegang krijgen tot accounts vanaf een ander apparaat.

Hoe het werkt

DBSC introduceert een nieuwe API waarmee servers een geverifieerde sessie kunnen creëren die aan een apparaat is gekoppeld. Wanneer een sessie wordt gestart, genereert de browser een publiek-privaat sleutelpaar, waarbij de privésleutel veilig wordt opgeslagen met behulp van door hardware ondersteunde opslag zoals een Trusted Platform Module (TPM), indien beschikbaar.

De browser geeft dan een reguliere sessiecookie uit. Tijdens de levensduur van de sessie bewijst de browser periodiek het bezit van de privésleutel en vernieuwt hij de sessiecookie. De levensduur van de cookie kan kort genoeg worden ingesteld, zodat het stelen van de cookie geen voordeel oplevert voor aanvallers.

Belangrijkste componenten

  • Sessie registratie :

    • Wanneer een gebruiker inlogt, vraagt ​​de server een apparaatgebonden sessie aan met behulp van de Sec-Session-Registration HTTP-header.
    • De browser genereert een nieuw sleutelpaar en slaat de privésleutel veilig op.
    • Er wordt ook een kortstondige authenticatiecookie ingesteld en aan dit sleutelpaar gekoppeld.
    • De server koppelt de sessie aan de bijbehorende publieke sleutel, zodat de sessie alleen op het originele apparaat kan worden gebruikt.

  • Sessie vernieuwen en bewijs van bezit :

    • Wanneer de kortstondige cookie verloopt, activeert Chrome een sessievernieuwing.
    • De browser stuurt een verzoek naar een door de server gedefinieerd vernieuwingseindpunt (verstrekt tijdens de sessieregistratie) en, als de server er een aanbiedt, een ondertekende uitdaging met behulp van de Sec-Session-Challenge header.
    • De server verifieert het bewijs van bezit door het antwoord te valideren dat is ondertekend met de privésleutel van de sessie.
    • Indien geldig, geeft de server een nieuwe kortstondige cookie uit, waardoor de sessie kan worden voortgezet.

Een voordeel van deze aanpak is dat Chrome verzoeken uitstelt die anders de vernieuwde kortstondige cookie zouden missen. Dit gedrag zorgt ervoor dat sessiegebonden cookies gedurende de hele sessie consistent beschikbaar zijn en stelt ontwikkelaars in staat er met meer vertrouwen op te vertrouwen dan bij benaderingen waarbij cookies kunnen verlopen of verdwijnen zonder automatische verlenging.

Voorbeeld implementatie

Een server kan als volgt een apparaatgebonden sessie aanvragen:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256);path="/refresh";challenge="12345"

Wanneer de sessie actief is, kan de server deze verifiëren met een challenge-response-uitwisseling:

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "verify-session"

De browser reageert met:

POST /refresh
Sec-Session-Response: "signed-proof"

Voordelen

  • Vermindert diefstal van cookies : zelfs als sessiecookies worden gestolen, kunnen ze niet vanaf een ander apparaat worden gebruikt.
  • Verbetert de beveiliging zonder grote UX-wijzigingen : Werkt transparant op de achtergrond zonder dat extra gebruikersinteractie nodig is.
  • Vermindert de afhankelijkheid van cookies met een lange levensduur : Cookies met een korte levensduur worden automatisch vernieuwd zolang de sessie geldig blijft op het oorspronkelijke apparaat.
  • Ondersteunt standaard cryptografische mechanismen : maakt gebruik van door TPM ondersteunde veilige opslag, indien beschikbaar, en biedt krachtige bescherming tegen exfiltratie.

Privacy- en veiligheidsoverwegingen

DBSC is ontworpen om de beveiliging te verbeteren en tegelijkertijd de privacy van gebruikers te behouden:

  • Geen extra trackingvectoren : elke sessie is gekoppeld aan een uniek sleutelpaar, waardoor tracking tussen sessies wordt voorkomen.
  • Geen langdurige apparaatvingerafdrukken : Servers kunnen geen verschillende sessies op hetzelfde apparaat correleren, tenzij dit expliciet wordt toegestaan ​​door de gebruiker.
  • Wisbaar door gebruikers : sessies en sleutels worden verwijderd wanneer de gebruiker sitegegevens wist.
  • In lijn met het cookiebeleid : DBSC volgt dezelfde sitegebaseerde scoping als cookies en zorgt ervoor dat er geen cross-origin datalekken ontstaan.

Probeer het eens

De Device Bound Session Credentials Origin-proefversie is beschikbaar vanaf Chrome 135.

Voor lokale testen

DBSC lokaal testen:

  • Ga naar chrome://flags#device-bound-session-credentials en schakel de functie in.

Voor openbare tests

DBSC testen met de origin-proefversie in een openbare omgeving:

  1. Ga naar de Chrome Origin-proefversiepagina en meld u aan.

  2. Voeg het opgegeven token toe aan de HTTP-headers van uw site:

    Origin-Trial: <your-trial-token>

Bronnen

Doe mee en geef vorm aan de toekomst van webbeveiliging

Help ons mee om webauthenticatie veiliger te maken! We moedigen webontwikkelaars aan om DBSC te testen, in hun applicaties te integreren en feedback te delen. U kunt met ons communiceren op GitHub of deelnemen aan discussies met de Web Application Security Working Group.

Door DBSC te implementeren, kunnen we gezamenlijk de risico's van sessiekaping verminderen en de authenticatiebeveiliging voor gebruikers verbeteren. Ga vandaag nog aan de slag en help mee de toekomst van webbeveiliging te definiëren!

,

José Luis Zapata

Device Bound Session Credentials (DBSC) is een nieuwe webfunctie die is ontworpen om gebruikerssessies te beschermen tegen cookiediefstal en sessiekaping. Deze functie kan nu worden getest als Origin-proefversie in Chrome 135.

Achtergrond

Cookies spelen een cruciale rol in moderne webauthenticatie, waardoor gebruikers ingelogd kunnen blijven tijdens browsersessies. Aanvallers maken echter steeds vaker misbruik van gestolen authenticatiecookies om sessies te kapen, waarbij multi-factor authenticatie en andere beveiligingsmechanismen voor inloggen worden omzeild.

Malware-exploitanten exfiltreren vaak sessiecookies van aangetaste apparaten, waardoor ongeautoriseerde toegang tot gebruikersaccounts mogelijk wordt. Omdat cookies dragertokens zijn, verlenen ze toegang zonder dat er een bewijs van bezit nodig is, waardoor ze een lucratief doelwit zijn voor aanvallers.

Device Bound Session Credentials (DBSC) heeft tot doel de diefstal van cookies te verstoren door een geverifieerde sessie te creëren die aan een apparaat is gekoppeld. Deze aanpak verkleint de kans dat geëxfiltreerde cookies toegang krijgen tot accounts vanaf een ander apparaat.

Hoe het werkt

DBSC introduceert een nieuwe API waarmee servers een geverifieerde sessie kunnen creëren die aan een apparaat is gekoppeld. Wanneer een sessie wordt gestart, genereert de browser een publiek-privaat sleutelpaar, waarbij de privésleutel veilig wordt opgeslagen met behulp van door hardware ondersteunde opslag zoals een Trusted Platform Module (TPM), indien beschikbaar.

De browser geeft dan een reguliere sessiecookie uit. Tijdens de levensduur van de sessie bewijst de browser periodiek het bezit van de privésleutel en vernieuwt hij de sessiecookie. De levensduur van de cookie kan kort genoeg worden ingesteld, zodat het stelen van de cookie geen voordeel oplevert voor aanvallers.

Belangrijkste componenten

  • Sessie registratie :

    • Wanneer een gebruiker inlogt, vraagt ​​de server een apparaatgebonden sessie aan met behulp van de Sec-Session-Registration HTTP-header.
    • De browser genereert een nieuw sleutelpaar en slaat de privésleutel veilig op.
    • Er wordt ook een kortstondige authenticatiecookie ingesteld en aan dit sleutelpaar gekoppeld.
    • De server koppelt de sessie aan de bijbehorende publieke sleutel, zodat de sessie alleen op het originele apparaat kan worden gebruikt.

  • Sessie vernieuwen en bewijs van bezit :

    • Wanneer de kortstondige cookie verloopt, activeert Chrome een sessievernieuwing.
    • De browser stuurt een verzoek naar een door de server gedefinieerd vernieuwingseindpunt (verstrekt tijdens de sessieregistratie) en, als de server er een aanbiedt, een ondertekende uitdaging met behulp van de Sec-Session-Challenge header.
    • De server verifieert het bewijs van bezit door het antwoord te valideren dat is ondertekend met de privésleutel van de sessie.
    • Indien geldig, geeft de server een nieuwe kortstondige cookie uit, waardoor de sessie kan worden voortgezet.

Een voordeel van deze aanpak is dat Chrome verzoeken uitstelt die anders de vernieuwde kortstondige cookie zouden missen. Dit gedrag zorgt ervoor dat sessiegebonden cookies gedurende de hele sessie consistent beschikbaar zijn en stelt ontwikkelaars in staat er met meer vertrouwen op te vertrouwen dan bij benaderingen waarbij cookies kunnen verlopen of verdwijnen zonder automatische verlenging.

Voorbeeld implementatie

Een server kan als volgt een apparaatgebonden sessie aanvragen:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256);path="/refresh";challenge="12345"

Wanneer de sessie actief is, kan de server deze verifiëren met een challenge-response-uitwisseling:

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "verify-session"

De browser reageert met:

POST /refresh
Sec-Session-Response: "signed-proof"

Voordelen

  • Vermindert diefstal van cookies : zelfs als sessiecookies worden gestolen, kunnen ze niet vanaf een ander apparaat worden gebruikt.
  • Verbetert de beveiliging zonder grote UX-wijzigingen : Werkt transparant op de achtergrond zonder dat extra gebruikersinteractie nodig is.
  • Vermindert de afhankelijkheid van cookies met een lange levensduur : Cookies met een korte levensduur worden automatisch vernieuwd zolang de sessie geldig blijft op het oorspronkelijke apparaat.
  • Ondersteunt standaard cryptografische mechanismen : maakt gebruik van door TPM ondersteunde veilige opslag, indien beschikbaar, en biedt krachtige bescherming tegen exfiltratie.

Privacy- en veiligheidsoverwegingen

DBSC is ontworpen om de beveiliging te verbeteren en tegelijkertijd de privacy van gebruikers te behouden:

  • Geen extra trackingvectoren : elke sessie is gekoppeld aan een uniek sleutelpaar, waardoor tracking tussen sessies wordt voorkomen.
  • Geen langdurige apparaatvingerafdrukken : Servers kunnen geen verschillende sessies op hetzelfde apparaat correleren, tenzij dit expliciet wordt toegestaan ​​door de gebruiker.
  • Wisbaar door gebruikers : sessies en sleutels worden verwijderd wanneer de gebruiker sitegegevens wist.
  • In lijn met het cookiebeleid : DBSC volgt dezelfde sitegebaseerde scoping als cookies en zorgt ervoor dat er geen cross-origin datalekken ontstaan.

Probeer het eens

De Device Bound Session Credentials Origin-proefversie is beschikbaar vanaf Chrome 135.

Voor lokale testen

DBSC lokaal testen:

  • Ga naar chrome://flags#device-bound-session-credentials en schakel de functie in.

Voor openbare tests

DBSC testen met de origin-proefversie in een openbare omgeving:

  1. Ga naar de Chrome Origin-proefversiepagina en meld u aan.

  2. Voeg het opgegeven token toe aan de HTTP-headers van uw site:

    Origin-Trial: <your-trial-token>

Bronnen

Doe mee en geef vorm aan de toekomst van webbeveiliging

Help ons mee om webauthenticatie veiliger te maken! We moedigen webontwikkelaars aan om DBSC te testen, in hun applicaties te integreren en feedback te delen. U kunt met ons communiceren op GitHub of deelnemen aan discussies met de Web Application Security Working Group.

Door DBSC te implementeren, kunnen we gezamenlijk de risico's van sessiekaping verminderen en de authenticatiebeveiliging voor gebruikers verbeteren. Ga vandaag nog aan de slag en help mee de toekomst van webbeveiliging te definiëren!