Chrome implementeert Device-bound session credentials (DBSCs), een nieuwe beveiligingslaag die is ontworpen om accountovernames via het stelen van sessiecookies tegen te gaan.
Hoe het werkt
In plaats van alleen te vertrouwen op cookies, slaat Chrome een unieke encryptiesleutel op in de hardwarematige beveiliging van het apparaat:
- Windows: TPM (Trusted Platform Module)
- macOS/iOS: Secure Enclave
Omdat deze sleutels fysiek geïsoleerd zijn, kunnen ze niet worden gestolen door infostealer-malware. Wanneer een gebruiker een site bezoekt, moet de browser een authenticatie-uitdaging ondertekenen met deze private sleutel. Zonder de juiste hardwarematige signatuur wordt de toegang geweigerd, zelfs als een aanvaller in het bezit is van de sessiecookie.
Status en Controle
De functie bevindt zich momenteel in een testfase voor specifieke versies van Chrome op Windows (v147) en macOS (v150). Gebruikers kunnen controleren of DBSCs actief zijn via de ontwikkelaarshulpmiddelen onder het tabblad 'Application'.
Chrome voert mogelijk de beste bescherming tot nu toe in tegen het overnemen van accounts
De Chrome-browser van Google heeft een nieuwe functie toegevoegd die een grote stap voorwaarts kan zijn in het voorkomen van een vorm van accountovername die steeds gebruikelijker is geworden nu gebruikers tweefactorauthenticatie (2FA), passkeys en soortgelijke beschermingen adopteren.
De nieuwe beveiliging van Chrome staat bekend als device-bound session credentials (DBSCs). Deze maatregel slaat een unieke encryptiesleutel op in een hardwarematige "vesting" die is ingebouwd in het apparaat waarop de browser draait. Op Windows-machines wordt deze vesting een TPM (Trusted Platform Module) genoemd; op macOS en iOS staat dit bekend als een secure enclave. Andere platforms gebruiken verschillende benamingen. Recent uitgebrachte versies van Chrome voor Windows en macOS genereren een sleutel die in deze beveiligde omgeving wordt opgeslagen.
Een tegengif voor het stelen van sessiecookies
DBSCs beschermen tegen de diefstal van sessiecookies: unieke reeksen tekens die websites in browsers opslaan. Sessiecookies versnellen het browsen op gevoelige sites waar gebruikersauthenticatie vereist is aanzienlijk. In plaats van dat er bij elke nieuwe pagina een uitwisseling van inloggegevens nodig is, stelt de server een sessiecookie in die effectief bewijst dat de gebruiker al succesvol is ingelogd.
De dreiging van het stelen van sessiecookies is toegenomen nu 2FA, passkeys en soortgelijke beschermingen gebruikelijker zijn geworden. Deze nieuwere beveiligingen vereisen extra factoren naast een gedeeld geheim voordat een gebruiker toegang krijgt tot een beperkte site. Omdat het bezit van enkel een wachtwoord niet langer voldoende is, zijn phishing en andere traditionele vormen van accountovername minder effectief geworden.
Om dit te compenseren, maken aanvallers in toenemende mate gebruik van infostealer-malware en adversary-in-the-middle-aanvallen. Beide vormen van aanval werken door sessiecookies te stelen. Aanvallers plakken deze cookies vervolgens in hun eigen browser en verkrijgen daarmee (ten minste tijdelijk) dezelfde toegang als de rechtmatige eigenaar.
DBSCs fungeren als een tegengif voor het stelen van sessiecookies. Zodra een website een sessiecookie instelt, moet de bezoekende browser een vorm van de cookie versturen die is ondertekend met de sleutel die in de hardware (silicon) is opgeslagen. Eigenschappen van de TPM of secure enclave isoleren de sleutel zodanig dat extractie wordt voorkomen.
Scott Helme, een onderzoeker en oprichter van Report URI, legt het proces als volgt uit:
"De aanvaller kan de private sleutel niet van het apparaat stelen omdat de TPM / Secure Enclave deze niet vrijgeeft. Dat is hier de kernbescherming. De aanvaller kan de cookie stelen, maar hij kan niet antwoorden op een DBSC-uitdaging door deze te ondertekenen met de private sleutel, die veilig op je apparaat blijft."
Beschikbaarheid en controle
Vooralsnog worden DBSCs alleen ondersteund in Chrome versie 147 voor Windows en versie 150 voor macOS. Zelfs dan zijn DBSCs slechts ingeschakeld voor een beperkte groep gebruikers; vermoedelijk test Google de functie voordat deze algemeen beschikbaar wordt gesteld.
Chrome-gebruikers op Windows en macOS kunnen controleren of de functie in hun browser actief is door:
- De ontwikkelaarshulpmiddelen (developer tools) te openen.
- Op het tabblad 'Application' bovenaan te klikken.
- Naar beneden te scrollen.
Wanneer een gebruiker is ingelogd op een site die DBSCs ondersteunt, verschijnt de melding "device bound sessions" als de beveiliging is ingeschakeld. Het is onduidelijk wanneer, of überhaupt of, andere Chromium-gebaseerde browsers DBSCs zullen implementeren, maar het is waarschijnlijk dat ze dit zullen doen.
Hoe het authenticatiemodel werkt
DBSCs zijn de nieuwste vorm van authenticatie die de afhankelijkheid van een gedeeld geheim elimineert—iets wat, zoals de wereld al jaren weet, pijnlijk eenvoudig voor aanvallers te stelen is.
Onder dit nieuwe model werkt het proces als volgt:
- Webservers slaan de publieke sleutel van de bezoeker op.
- De servers sturen vervolgens een authenticatie-uitdaging (authentication challenge) die de sessiecookie bevat.
- Tenzij het resulterende antwoord, bekend als een authentication assertion, is ondertekend door de private sleutel die veilig in de TPM of secure enclave is opgeslagen, wordt de bewering afgewezen.
Passkeys werken op exact dezelfde manier.
Chrome voert mogelijk de beste bescherming tot nu toe in tegen het overnemen van accounts
De Chrome-browser van Google heeft een nieuwe functie toegevoegd die een grote stap voorwaarts kan zijn in het voorkomen van een vorm van accountovername die steeds gebruikelijker is geworden nu gebruikers tweefactorauthenticatie (2FA), passkeys en soortgelijke beschermingen adopteren.
De nieuwe beveiliging van Chrome staat bekend als device-bound session credentials (DBSCs). Deze maatregel slaat een unieke encryptiesleutel op in een hardwarematige "vesting" die is ingebouwd in het apparaat waarop de browser draait. Op Windows-machines wordt deze vesting een TPM (Trusted Platform Module) genoemd; op macOS en iOS staat dit bekend als een secure enclave. Andere platforms gebruiken verschillende benamingen. Recent uitgebrachte versies van Chrome voor Windows en macOS genereren een sleutel die in deze beveiligde omgeving wordt opgeslagen.
Een tegengif voor het stelen van sessiecookies
DBSCs beschermen tegen de diefstal van sessiecookies: unieke reeksen tekens die websites in browsers opslaan. Sessiecookies versnellen het browsen op gevoelige sites waar gebruikersauthenticatie vereist is aanzienlijk. In plaats van dat er bij elke nieuwe pagina een uitwisseling van inloggegevens nodig is, stelt de server een sessiecookie in die effectief bewijst dat de gebruiker al succesvol is ingelogd.
De dreiging van het stelen van sessiecookies is toegenomen nu 2FA, passkeys en soortgelijke beschermingen gebruikelijker zijn geworden. Deze nieuwere beveiligingen vereisen extra factoren naast een gedeeld geheim voordat een gebruiker toegang krijgt tot een beperkte site. Omdat het bezit van enkel een wachtwoord niet langer voldoende is, zijn phishing en andere traditionele vormen van accountovername minder effectief geworden.
Om dit te compenseren, maken aanvallers in toenemende mate gebruik van infostealer-malware en adversary-in-the-middle-aanvallen. Beide vormen van aanval werken door sessiecookies te stelen. Aanvallers plakken deze cookies vervolgens in hun eigen browser en verkrijgen daarmee (ten minste tijdelijk) dezelfde toegang als de rechtmatige eigenaar.
DBSCs fungeren als een tegengif voor het stelen van sessiecookies. Zodra een website een sessiecookie instelt, moet de bezoekende browser een vorm van de cookie versturen die is ondertekend met de sleutel die in de hardware (silicon) is opgeslagen. Eigenschappen van de TPM of secure enclave isoleren de sleutel zodanig dat extractie wordt voorkomen.
Scott Helme, een onderzoeker en oprichter van Report URI, legt het proces als volgt uit:
"De aanvaller kan de private sleutel niet van het apparaat stelen omdat de TPM / Secure Enclave deze niet vrijgeeft. Dat is hier de kernbescherming. De aanvaller kan de cookie stelen, maar hij kan niet antwoorden op een DBSC-uitdaging door deze te ondertekenen met de private sleutel, die veilig op je apparaat blijft."
Beschikbaarheid en controle
Vooralsnog worden DBSCs alleen ondersteund in Chrome versie 147 voor Windows en versie 150 voor macOS. Zelfs dan zijn DBSCs slechts ingeschakeld voor een beperkte groep gebruikers; vermoedelijk test Google de functie voordat deze algemeen beschikbaar wordt gesteld.
Chrome-gebruikers op Windows en macOS kunnen controleren of de functie in hun browser actief is door:
- De ontwikkelaarshulpmiddelen (developer tools) te openen.
- Op het tabblad 'Application' bovenaan te klikken.
- Naar beneden te scrollen.
Wanneer een gebruiker is ingelogd op een site die DBSCs ondersteunt, verschijnt de melding "device bound sessions" als de beveiliging is ingeschakeld. Het is onduidelijk wanneer, of überhaupt of, andere Chromium-gebaseerde browsers DBSCs zullen implementeren, maar het is waarschijnlijk dat ze dit zullen doen.
Hoe het authenticatiemodel werkt
DBSCs zijn de nieuwste vorm van authenticatie die de afhankelijkheid van een gedeeld geheim elimineert—iets wat, zoals de wereld al jaren weet, pijnlijk eenvoudig voor aanvallers te stelen is.
Onder dit nieuwe model werkt het proces als volgt:
- Webservers slaan de publieke sleutel van de bezoeker op.
- De servers sturen vervolgens een authenticatie-uitdaging (authentication challenge) die de sessiecookie bevat.
- Tenzij het resulterende antwoord, bekend als een authentication assertion, is ondertekend door de private sleutel die veilig in de TPM of secure enclave is opgeslagen, wordt de bewering afgewezen.
Passkeys werken op exact dezelfde manier.
Groetjes,