Google Chrome experimenteert met alternatief voor authenticatiecookies

Google Chrome experimenteert met Device Bound Session Credentials, sessiesleutels die de huidige authenticatiecookies mogelijk kunnen vervangen. De huidige cookies zijn vatbaar voor diefstal door criminelen, wat DBSC moet verhelpen.

DBSC is een authenticatiemethode die werkt met privésleutels en een api voor websites. Als een gebruiker inlogt bij een website, wordt er een privésleutel aangemaakt die wordt opgeslagen op het systeem van de gebruiker. De website controleert periodiek en automatisch of de sleutel overeenkomt met het systeem en het account.

Het verschil tussen DBSC en huidige authenticatiecookies is dat de DBSC-sleutels gekoppeld zijn aan het systeem van een gebruiker. Het stelen van een DBSC-sleutel zou dus niet genoeg moeten zijn. Daarnaast gebruikt de DBSC-sleutel de TPM 2.0-chip van een pc, waardoor malware de sleutels moeilijker kan stelen. TPM 2.0 is verplicht voor Windows 11-pc's, maar bij eerdere Windows-versies was dit niet het geval. Google zegt op GitHub dat ongeveer zestig procent van de Windows-pc's over een TPM 2.0-chip beschikt. Het bedrijf overweegt softwarematige alternatieven voor gebruikers zonder TPM 2.0-chip.

Google benadrukt dat de DBSC-sleutels per sessie uniek zijn, en dat sites en adverteerders de DBSC's niet kunnen gebruiken om individuele systemen te herkennen en tracken. DBSC kan dan ook niet ingezet worden voor advertentiedoeleinden. Gebruikers kunnen de DBSC-sleutels verwijderen in de Chrome-instellingen.

Het bedrijf werkt al langer aan DBSC en zegt op dit moment te experimenteren met een prototype bij Chrome Bèta-gebruikers. Google spreekt over een 'vroeg initiatief' om de betrouwbaarheid, haalbaarheid en latency van het protocol te kunnen testen. Op dit moment werkt DBSC alleen nog met het Google Account, later moeten Workspace en Cloud hier ook onder vallen. Andere bedrijven en partijen, waaronder Microsoft met Edge en identiteitsdiensten als Okta, hebben volgens Google interesse getoond in DBSC. Externe websites zouden eind 2024 de eerste tests kunnen uitvoeren.

De huidige authenticatie- of sessiecookies zijn kwetsbaar doordat criminelen ze relatief eenvoudig kunnen stelen. Omdat de cookies aangemaakt zijn nadat de gebruiker is ingelogd, kunnen criminelen 2fa en andere accountbeveiligingen omzeilen. Doordat DBSC gekoppeld is aan het systeem van een gebruiker en de TPM 2.0-chip gebruikt, zou deze authenticatiemethode niet vatbaar zijn voor de kwetsbaarheden in de huidige cookies.

Reacties (102)

[GarBaGe]

Dat klinkt wel heel erg als een passkey....

[multiplexer]

Misschien ten overvloede, als je al precies weet hoe passkeys en authenticatie werken... maar misschien interessant voor sommigen:

Dit nieuwe idee borduurt voort op dezelfde concepten als passkeys (domain-bound private keys en secure storage in TPM of Secure Enclave), maar met als fundamenteel verschil het toepassingsgebied. Passkeys gebruik je om in te loggen - oftewel: "Hey website, ik wil inloggen, hier is mijn public key die ik voor <tweakers.net> heb opgeslagen. Stuur me eens een challenge die ik met de private key die ik voor deze site heb gegenereerd kan oplossen.". Als je die challenge succesvol oplost ben je ingelogd.

Maar wat is dat eigenlijk, ingelogd zijn? Eigenlijk niks meer of minder dan dat je browser bij elke request een token meestuurt, die je een keertje van de server hebt gekregen nadat die vaststelde dat je credentials inderdaad klopten. Die token moet de browser vervolgens ergens onthouden. Dat is waar heden ten dage cookies gebruikt worden (of soms de Local Storage in de browser, in geval van single-page applications). Als iemand toegang tot de files op je harde schijf heeft kan hij/zij die cookie dus uitlezen, en zelf gebruiken. Dit is waarom andere reageerders het hebben over 2FA bypasses.
Vroeger kon dit ook door malafide javascript in een website te injecteren (Cross-site Scripting attacks), omdat de browser geen onderscheid maakte tussen "dit is een cookie met een token die alleen voor de server nuttig is" vs "dit is een cookie met lokaal opgeslagen info". Tegenwoordig kun je met de "HttpOnly" flag aangeven dat een cookie niet aan Javascript ge-exposed mag worden... of alle developers dit ook netjes doen laat zich raden, maar een beetje security-minded dev past dit toe.

Wat dit voorstel doet is dus eigenlijk de concepten achter passkeys doortrekken naar die sessie-tokens. Als ik het goed begrijp (en hou me ten goede, ik heb alleen het T.net artikel gelezen, nog niet de bron) wordt er niet langer een token opgeslagen, maar genereer je een public/private key pair, en stuur je de public key naar de server toe. In plaats van dat er een Cookie-header meegestuurd wordt gaat 'ie elke request cryptografisch signen met die public key, zodat de server met de bijbehorende private key kan valideren dat de request inderdaad bij jou vandaan komt.

In tegenstelling tot passkeys zijn deze DBSC-keys dus ook gebonden aan één systeem, en is het niet de bedoeling dat je ze kunt overdragen naar andere apparaten. Als je op een ander apparaat wilt inloggen moet je opnieuw je credentials (username. password, 2fa, passkey) aanbieden en krijg je een nieuwe sessie.

[Reactie gewijzigd door multiplexer op 22 juli 2024 16:13]

[maartuhvh]

Goed verhaal, fijne samenvatting.

Wat dit voorstel doet is dus eigenlijk de concepten achter passkeys doortrekken naar die sessie-tokens. Als ik het goed begrijp (en hou me ten goede, ik heb alleen het T.net artikel gelezen, nog niet de bron) wordt er niet langer een token opgeslagen, maar genereer je een public/private key pair, en stuur je de public key naar de server toe. In plaats van dat er een Cookie-header meegestuurd wordt gaat 'ie elke request cryptografisch signen met die public key, zodat de server met de bijbehorende private key kan valideren dat de request inderdaad bij jou vandaan komt.

Kan het zijn dat je in het tweede deel public en private hebt omgedraaid? Het request wordt dan gesigned met de private, en aan de server kant gevalideerd met de public.

[vrow]

Lijkt inderdaad omgedraaid.
Komt omdat het meestal ook omgedraaid is.
Als je een versleuteld bericht naar iemand wilt sturen, versleutel je het met zijn public key en daarna kan hij het met zijn eigen private key ontsleutelen. Eén ontvanger kan het dus lezen.
Maar bij het ondertekenen van een bericht, onderteken je het juist met je eigen private key en kan iedereen met behulp van jouw public key, controleren dat het van jou afkomstig is. Iedereen kan verifiëren.

(en bericht kan een mail zijn, of een chat-bericht maar ook een HTTP-request is in deze context een bericht).

[multiplexer]

Je hebt uiteraard helemaal gelijk.

Heb de oorspronkelijke tekst even doorgelezen, en het ligt nog net iets anders. Tijdens het inloggen geeft de server aan op welk endpoint de browser short-lived (in-memory) cookies kan opvragen, die vervolgens gebruikt worden voor de sessie. Zo lang de gebruiker actief blijft op de site zal de browser op de achtergrond om de zoveel tijd dit endpoint aanspreken om nieuwe short-lived cookies op te halen, zodat dit geen extra roundtrip kost bij de normale requests. Best slim!

[Reactie gewijzigd door multiplexer op 22 juli 2024 16:13]

[Sebazzz]

Vroeger kon dit ook door malafide javascript in een website te injecteren (Cross-site Scripting attacks), omdat de browser geen onderscheid maakte tussen "dit is een cookie met een token die alleen voor de server nuttig is" vs "dit is een cookie met lokaal opgeslagen info". Tegenwoordig kun je met de "HttpOnly" flag aangeven dat een cookie niet aan Javascript ge-exposed mag worden... of alle developers dit ook netjes doen laat zich raden, maar een beetje security-minded dev past dit toe.

Tegenwoordig gooien we JWT voor de Single Page Application toch in de localstorage, waardoor alle voordelen van HttpOnly cookies teniet gedaan wordt

[djwice]

Dat 'tegenwoordig' speelt al bijna 10 jaar als het niet meer is.
Ik heb lang geleden zelfs een ontwerp gemaakt waarbij de single page app niet eens bij de auth info hoefde.

Maar op de een of andere manier denken mensen dat de front end die token nos g heeft. Terwijl je de __Host- prefixed cookie best netjes op je API path kunt zetten zodat ie nergens anders wordt weggestuurd.

[eurob]

Goed uitgelegd

[Rafe]

Het deed mij denken aan token binding, waarmee je cookies (en andere zaken zoals een WebAuthn assertion) aan de private key van TLS-channel kan verbinden en zo ook onderschepte data onbruikbaar maakt.

De standaard hiervoor is RFC 8471 maar helaas werd in 2020 ondersteuning uit Chrome werd verwijderd (ondanks tegengeluid): https://groups.google.com...kdLUyYmY1E/m/w2ESAeshBgAJ

[Reactie gewijzigd door Rafe op 22 juli 2024 16:13]

[multiplexer]

En webbankieren! Want webbankieren gebruikt ook al sinds inceptie privésleutels! En SSH-sessies!

Dit klinkt echt totaal niet "als een blockchain". De enige overeenkomst is dat ze beiden op public/private keys voortbouwen... maar dat is net als zeggen dat mijn huis op de Taj Mahal lijkt, omdat ze allebei stenen gebruiken. En geloof me... mijn Vinex-doos zal niemand verwarren met de Taj Mahal.

[Petervf]

Bij blockchain IS je private key je authenticatiemechanisme. Bij de hier beschreven oplossing is er een bestaande vorm van authenticatie, en vervangen de DBSC-sleutels de bestaande cookies. Bij webbankieren wordt er een private key gebruikt voor de versleutelde verbinding.

Wat deze 3 zaken gemeen hebben is dat ergens op het pad een privésleutel wordt gebruikt, alleen voor 3 verschillende doeleinden. Blockchain is geen betere vergelijking dan webbankieren. Het is beide vergezocht.

Het is alsof ik bij een post over blockchain over Minecraft begin. Daarin zitten ook linked lists, en het gaat via internet, dus da's gewoon net blockhain.

De oorspronkelijke vergelijking met een passkeys gaat veel beter op.

[latka]

Is dit serieus?

[Minimise]

Ja, de voorafgaande ontwerpen waren met wachtwoord en cookies als standaard, en slechts privé sleutel als backup, maar blockchain verwijderde wachtwoord- en cookie authenticatie volledig van het ontwerp!

[Reactie gewijzigd door Minimise op 22 juli 2024 16:13]

[latka]

Een blockchain is een blobje bitjes. De logica eromheen bepaal de toegang. Dus ik snap je punt niet helemaal. Dat de blockchain bestaat uit gesignde informatie is leuk maar als ik die blob van jou kan jatten dan zijn het mijn bitjes en mijn bitcoins geworden. Als ik mijn syslog hash met de vorige regel als salt heb ik ook een blockchain, maar mijn Unix bak ondersteunt gewoon nog een login met username/passwoord op de console.

[Minimise]

“ maar als ik die blob van jou kan jatten” <— zowel symmetrisch als asymmetrische cryptografie draaien erom dat je de privé sleutel juist niet kan jatten, anders is het voor niks! “ Als ik mijn syslog hash met de vorige regel als salt heb ik ook een blockchain” <— nee, dat is slechts een variant van een LinkedList! Voor een blockchain dien je feitelijk alle hoofdzakelijke regels uit de bitcoin code dump te implementeren!

[Reactie gewijzigd door Minimise op 22 juli 2024 16:13]

[k995]

Lol langs geen kanten

[graceful]

Gezien session-stealers steeds normaler worden en mensen steeds verbaast zijn hoe het kan dat iemand de 2FA heeft weten te omzeilen, is een andere aanpak geen slecht idee.

Al ben ik wel wat sceptisch als het gaat om verplichten van koppelingen met Google Accounts en dergelijk. Daarmee maak je toch meteen de veiligheid ongedaan? Een account en je bezit meteen weer alle sessions. Zie nog niet helemaal waarom er een account bij zou moeten horen. Doel is toch lokaal opslaan.

[TheVivaldi]

Bijna alle tweakers: “2FA is veilig en niet te onderscheppen/omzeilen!!!”
Tweaker graceful: “Mensen zijn steeds verbaasd dat iemand de 2FA heeft weten te omzeilen.”

[lenwar]

Zegt dit iets over bijna alle tweakers of zegt dit iets over @graceful? 2FA is natuurlijk per definitie een goed idee. Maar de meestgebruikte vorm van 2FA (TOTP) is nou niet echt de sterkste/beste vorm van 2FA. We moeten ons er zeker niet op blind staren.

TOTP heeft echt een paar hele goede voordelen. Het is offline. Het is publiek gedocumenteert algoritme, waardoor je niet vast zit aan een specifieke applicatie of bedrijf. Je stuurt nooit je sleutel/seed over de lijn wanneer hij eenmaal is ingesteld. Maar het is zeker niet feilloos.
Doordat het offline is, weet je nooit of iemand je seed/sleutel heeft gestolen/gekopieerd, of wanneer deze is gebruikt door een ander. Het is een 'shared secret'. Zowel de gebruiker als de dienst hebben dezelfde seed/sleutel in bezit. Als een kwaadwillende dus de wachtwoorddatabase heeft gestolen van de dienst, heeft die dus alle seeds, waardoor 2FA voor die dienst niets meer uithaalt. Alle gebruikers moeten dan hun TOTP-seed gaan vervangen. Prettige wedstrijd!!

Al met al dus niet een fantastische implementatie voor alle doeleinden.

Maar nogmaals. Iedere vorm van 2FA is beter dan geen 2FA.

Of 2FA wel of niet te onderscheppen/omzeilen is, hangt puur af van de kunde van de beheerder van de dienst. Zodra het mogeijk is, om de 2FA uit te schakelen via een wachtwoordreset of zo, is het dus te omzeilen. TOTP functioneerd prima met een MITM. (je hebt alleen maar een korte tijd om het te gebruiken)

[XIU]

maar dat is allemaal initieel, vanaf je geauthenticeerd bent, inclusief de 2FA check krijg je nog steeds een session token die je vanaf dan ook op andere plekken kan gebruiken

[lenwar]

Klopt.
Ik heb het ook puur over het stukje 2fa.
Het is beter dan niets, maar je moet je er niet blind op staren.

Wat je aangeeft is ook zeker een valide punt. Nou zijn er natuurlijk mechanismen om die sessietoken aan een instance (stuk hardware/software) te koppelen, maar dan moet dat wel zijn ingeregeld.
Met een app is dat bijvoorbeeld heel makkelijk te doen. Met een browser al een stuk lastiger. (Ook niet onmogelijk natuurlijk, maar wel lastiger om waterdicht te maken, zonder dat dat voor veel gebruiksfouten zorgt).
Ook kun je het bijvoorbeeld al heel goor doen door het aan een IP-adres te koppelen, maar dan is je gebruikerservaring met telefoons is dan heel bagger (tussen wifi en 4g schakelen) en je vangt ook lang niet alles af.

[warp]

Tweaker @graceful heeft zeker een punt. 2FA maakt de boel een stuk veiliger, maar onfeilbaar is het zeker niet. Zie bijvoorbeeld:
nieuws: 'Aanvallen via ss7-protocol om 2fa-sms'jes te onderscheppen nemen toe'
https://deictexpert.nl/kn...icatie-gefaald-heeft.html

[bzzzt]

De lange uitleg is: 2FA via SMS is niet veilig voor SIM swaps of mobiele providers die slordig omgaan met abonnementen.

[graceful]

Ik gebruik enkel het woord "omzeilen" omdat mensen dit zo uitspreken, wanneer ze door een session-stealer aangevallen zijn. Ik zeg nergens dat 2FA niet veilig is, of niet veiliger maakt. Het is enkel een veel gehoorde opmerking van mensen, zodra ze dan 'gehackt' zijn, dat ze niet begrijpen waarom omdat ze "toch 2FA hebben".

Waarom je mij daar persoonlijk op moet aanvallen ontgaat mij dan weer.

[Creesch]

Je positioneert het nu lekker zwart wit. De realiteit is echter dat 2fa toch echt veiliger is dan het niet hebben.
Het bemachtigen van valide wachtwoorden is namelijk vele malen makkelijker dan het stelen van een valide session cookie.

Wat graceful stelt klopt wat mij betreft ook niet. Het is het niet het omzeilen van 2fa, het is een andere aanvalsvector.

[multiplexer]

Mwoah. Ik vind omzeilen in dit geval wel een treffende omschrijving van hoe het werkt.

Vergelijk het met een club - bij de ingang staat een potige bewaker die bezoekers controleert. Allerlei checks: heb je een ticket, klopt je foto, weet je het wachtwoord (3FA - such secure, much safe, very wow!). En zodra je gechecked bent krijg je een (unieke) stempel op je hand, zodat je niet bij elk bezoek aan die club opnieuw door de hele check hoeft. Voor alles wat je in de club wilt doen heb je zo'n stempel nodig, en de bouncer zorgt er voor dat alleen mensen met zo'n stempel binnen mogen komen.

Vervolgens staat er een schimmig figuur in een steegje naast de club: "Pssst. Hey... Pssst. Ik heb gratis bitcoins... pssst!" (oftewel: een malafide link, of iets anders). Zodra iemand de steeg inloopt leiden ze je af (de cyber-aanval), en ze een foto van de unieke stempel op je hand (exfiltratie van je data) en maken die na op hun eigen hand. Vervolgens lopen ze naar de bewaker, die vriendelijk knikt en ze doorlaat. Mission accomplished, en de aanvaller kan nu met jouw privileges alles doen wat 'ie wil.

Hiermee omzeil je als aanvaller effectief de 2FA, door je aanval te richten op het proces achter de inlog, in plaats van de 2FA zelf.

Wat dit voorstel van Chrome effectief doet is die stempel vervangen. De metafoor loopt een beetje scheef, maar: je krijgt van de bewaker nu een sleutel voor een hokje dat voor de club neergezet wordt. Die sleutel is niet te kopieren, want die bewaar je natuurlijk op een plek waar de camera's van de aanvaller niet bij kunnen (onder je kleding? Dus: je TPM of secure enclave... metaforen zijn lastig!). In dat hokje staat een stempelkussen waarmee je jezelf alsnog een stempeltje kan geven, met als groot verschil dat deze stempels na 5 minuten vervagen (in-memory, time-limited cookies).

[ultimasnake]

Je hoeft 2FA niet te omzeilen als de authenticatie-cookie pas wordt verkregen na het inlogprocess. Er is helaas bar weinig waar je als developer aan vast kan houden om een cookie uniek genoeg te maken zonder in te leveren op gebruiksvriendelijkheid.

[moonlander]

Je kan dan eventueel cookie sessies koppelen aan een ipadres.

[OttoRocketman]

Dan zul je continu worden uitgelogd wanneer je op een mobiel netwerk zit of als je verbindt met verschillende wifi netwerken (kantoor, thuis, etc.).

[cracking cloud]

Succes als je op een netwerk zit waar je ip vaak wijzigt (bv van wifi naar 5g), of als je op een netwerk zit samen met duizenden andere mensen op hetzelfde IP (bv 5g)

[DvanRaai89]

Maar ja dan zit je ook weer met dingen als dynamische IP-addressen en ook op mobiel heb je steeds 'n andere, dus dat is ook geen optie.
Ik denk dat 't allemaal sowieso bar weinig verschil gaat maken omdat waneer je een cookie kunt stelen, in principe ook een proxy op zou kunnen zetten. Als je toch toegang tot 't apparaat hebt...

[BugBoy]

Helemaal nog niet zo'n slecht idee, maar met dynamische IP adressen is dat best nog wel vervelend. Je moet dan opnieuw inloggen als je van IP wisselt. Je zou na het inloggen het nieuwe IP adres kunnen toevoegen aan je cookie, zodat wisselen tussen thuis/werk slechts in totaal 2x inloggen betekent. Maar als je ISP een DHCP met korte lease heeft, dan kan het best wel eens vervelend worden. Ook zal je de IP adressen in je cookie moeten encrypten, want anders kunnen ze wellicht nog gespoofed worden.

[Vorlon]

Sommige vpn systemen doen dat inderdaad. En dat is vreselijk irritant. Want de laptop van de dock halen betekend een verbroken vpn verbinding. En omgekeerd weer.

[ultimasnake]

Het is een heel slecht idee, zeker in de praktijk. Als je voor grote multinationals werkt zal je al snel leren dat er niet iets bestaat als "1 uitgaand ip-address", je gebruiker kan ieder minuut uit een heel andere ip-address data opvragen, zelfs soms binnen dezelfde pagina "waterfall".

Gebruik je een VPN dienst dan kan dit ook enorm verschillen of deze statisch blijft in je sessie of regelmatig switched etc. En dan inderdaad wat anderen al zeggen als je op een 5G netwerk zit wordt het allemaal nog net wat erger.

[sympa]

Als dat cookie steeds via de TPM wordt ververst dan kan een attacker die verversing niet uitvoeren. Tenzij die permanente toegang heeft tot jouw TPM natuurlijk. Wat overeenkomt met het steeds openiuw stelen van je cookie.
Een virtuele TPM is natuurlijk ook al beter dan een vast cookie.

[Zo af en toe...]

Het zou kunnen dat het verplichte Google account alleen nodig is in de testfase. Ik kan me voorstellen dat als andere partijen instappen dit zal veranderen.

Zelf vind ik het niet zo erg omdat ik al een Google account heb vanwege YouTube en andere Google services, maar kan me best wel indenken dat anderen dat niet mij eens zijn.

[Skit3000]

Opzich weet Google al genoeg andere zaken over je systeem dat ze je eigenlijk al vast kunnen stellen wie hun site bezoekt zonder ook maar één cookie te plaatsen of je om een wachtwoord of iets dergelijks te vragen.

[fwiffo]

Cookies leven de hele sessie, bij elk request, en zijn voornamelijk voor het identificeren van een sessie (mits niet stateless).
Dat betekent ook dat een derde partij dit token zou kunnen gebruiken om de sessie over te kunnen nemen.

Hiermee echter wordt periodiek de sessie geauthenticeerd. Dit is los van een cookie.
Het kan simpelweg gebeuren door een challenge/response te doen met versleutelde data. Bijv server stuurt encrypted data met zijn asymmetrische sleutel. Cliënt decrypt deze en voegt een timestamp toe, en encrypt dit met zijn asymmetrische sleutel. Nu kan alleen de server dit lezen, en daarmee bevestigen dat de sessie nog steeds met de juiste partij is.

Dit kan al wel, maar de sleutel was in de browser zelf beschikbaar, dus ook daar uit te lezen voor malafide partijen. Dat is heel anders dan via tpm

[Bouwer21000]

Ik hoop dat hier een open protocol uit volgt voor alle browsers zodat het geen Chromium-exclusive trucje wordt, anders is de waarde er wel vanaf. Het klinkt wel als een degelijke poging om cookie stealing tegen te gaan. Benieuwd wat eruit komt.

[Demonitzu]

To address this problem, we’re prototyping a new web capability called Device Bound Session Credentials (DBSC) that will help keep users more secure against cookie theft. The project is being developed in the open at github.com/WICG/dbsc with the goal of becoming an open web standard.

https://blog.chromium.org...e-theft-using-device.html

[Reactie gewijzigd door Demonitzu op 22 juli 2024 16:13]

[Grimm]

Een browser die toegang heeft tot de TPM en mij zodoende perfekt (als in uniek) kan herkennen?
Nee dankje, mijn TPM staat uit in de bios en dat blijft zo.

[IStealYourGun]

Met welke reden wil je die niet aanzetten?

[Grimm]

Een TPM heeft geen toegevoegde waarde voor de gebruiker van de pc.
Het zijn de techgiganten en cohorten die (meer) controle willen over wat jij kunt/mag doen met je pc.
Daarvoor hebben ze de TPM nodig. Bijvoorbeeld om een abonnement of een licentie te koppelen aan een pc.
Zij vertrouwen mij niet maar verwachten wel dat ik hen vertrouw.

[laurxp]

Een TPM kan weldegelijk toegevoegde waarde hebben.

Een goed voorbeeld hiervan is het gebruik van Secure Boot met Bitlocker: het is alleen mogelijk om de schijf te decrypten met 1 specifieke machine, die boot met het juiste BIOS, de juiste bootloader, en de juiste kernel. Doe de schijf in een andere machine, en hij is niet te lezen. Boot dezelfde machine met een Linux USB, en hij is niet te lezen. Zet er een kernel op met een of andere keylogger, en hij is niet te lezen. Dit beschermt je dus tegen een hele hoop Evil Maid aanvallen.

Ik zie ook waarde in de TPM voor bijvoorbeeld SSH-sleutels. Praktisch iedereen gebruikt voor alles dezelfde SSH-sleutel, en ook nog eens dezelfde sleutel op meerdere machines. Dit is gewoon een simpel tekstbestandje dat op je schijf staat, dat vaak niet eens ge-encrypt is. Een perfect doelwit voor malware, dus! Je zou ook je TPM als SSH-sleutel kunnen gebruiken, waardoor deze onmogelijk te stelen is. Laat de TPM de sleutel genereren in plaats van een gedeelde te importeren, en je kan ook nog eens garanderen dat een login-poging van een specifieke machine komt.

[svennd]

Dat is wel een zeer enge benadering van TPM. Dat het ervoor (mis)bruikt kan worden zal ongetwijfeld wel, maar dat is niet de essentie. Nu linkt microsoft bijvoorbeeld je hardware onderdelen aan je windows licentie.

Ik zie dat niet snel aan tpm hangen, want die kun je gewoon als user resetten een fresh install zou dan niet kunnen want je key is veranderd.

[IStealYourGun]

Licenties en subscriptions worden vandaag zonder tpm toch ook al gekoppeld aan een device of user account. Ik zie niet hoe het uitschakelen van tpm dat gaat tegenhouden.

[bzzzt]

Een browser heeft daar helemaal geen TPM voor nodig. Bovendien zou een browser jou moeten beschermen tegen websites die proberen jou aan de hand van device eigenschappen te tracken. Dat doen Firefox, Safari en een aantal anderen vrij aardig, maar vrijwel iedereen gooit vrijwillig de browser van reclameboer Google op z'n systeem omdat die zo goed zou zijn...

[The Zep Man]

Dat doen Firefox, Safari en een aantal anderen vrij aardig,

Twijfel.

[bzzzt]

Zo'n site zegt niet alles. Chrome doet net alsof ze privacy bieden, maar onder water gaat alles naar Google...

[The Zep Man]

Zo'n site zegt niet alles.

Zo'n site zegt juist heel veel, ongeacht welke browser je gebruikt. Dit terwijl het voor veel zaken niet nodig is om veel van de gebruikte gegevens op te vragen (zoals het gebruikte besturingssysteem).

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:13]

[bzzzt]

Wat jij beschrijft zijn de algemene mogelijkheden die websites kunnen gebruiken om tracking toe te passen.

Google is ook actief bezig deze mogelijkheden in te dammen omdat zij ook een eigen browser met fors aandeel hebben en via die weg aan dezelfde informatie kunnen komen. Zeg maar 'de brug ophalen' voor concurrenten van hun advertentie business.

[Caelorum]

Hoe denk je dat ze je kunnen tracken? Het hele idee van de TPM is nou net dat je dingen uniek cryptografisch kan signen zonder dat die unieke key bekend is bij de software of zelfs maar in memory ergens komt te staan.

[laurxp]

Dat unieke sleutelpaar bestaat uit een geheim en een publiek component. Om de signature te valideren moet de tegenpartij het publieke component hebben.

Google slaat het publieke component op, en vraagt de PC met enige regelmaat om een bericht te ondertekenen met het geheime component. Dit kan alleen dezelfde TPM doen, want de geheime sleutel verlaat inderdaad nooit de TPM. Doe dit voor twee requests, en het is onomstotelijk bewezen dat de twee requests van dezelfde PC (want dezelfde TPM) komen - oftewel tracking.

[svane]

Gelukkig krijgt elke sessie zijn eigen sleutel. Dus 1 user heeft op termijn tig verschillende keys, waarvan Google/Chrome niet weet welke afkomstig zijn van dezelfde gebruiker.

https://blog.chromium.org...e-theft-using-device.html

Each session is backed by a unique key and DBSC does not enable sites to correlate keys from different sessions on the same device, to ensure there's no persistent user tracking added. The user can delete the created keys at any time by deleting site data in Chrome settings. The out-of-band refresh of short-term cookies is only performed if a user is actively using the session (e.g. browsing the website).

[laurxp]

In dit specifieke voorstel, ja. Maar als Chrome toegang heeft tot de TPM, heeft het dus ook toegang tot een waterdichte methode om betrouwbaar tracking te doen. Gezien Google's reputatie en de pogingen van de EU om bestaande tracking-methodes te stoppen, is er een vrij grote kans dat ze hier op termijn misbruik van gaan maken. Het is een kwestie van de kat niet op het spek willen binden.

[Reactie gewijzigd door laurxp op 22 juli 2024 16:13]

[wica]

Oww, leuk dat de browser bij bepaalde TPM gegevens kan. Zoals mijn unique identifier van mijn device.
waardoor de device te volgens is vanaf de aankoop..

[Alxndr]

Dit klinkt zo logisch dat je je afvraagt waarom het niet al jaren zo werkt. Dit is toch de manier waarop LTT de controle over zijn hele kanaal vorig jaar verloor?

Maargoed, TPM... dit zou toch moeten kunnen werken op een 3700X? Ik heb me er nooit in verdiept omdat ik geen Windows 11 wil.

En hoe snel kunnen we iets dergelijks voor Firefox (en andere browsers) verwachten?

[BugBoy]

Ik ben een beetje sceptisch als Google hiermee komt, want zij leven van advertenties en hebben dus juist belang bij tracking. Dit zullen ze enkel invoeren als ze de gebruiker op een andere manier kunnen tracken, want anders kost het ze teveel geld. Ik verwacht juist dat Google toch wel kan tracken (op een andere wijze) en hiermee de concurrentie buiten spel wil zetten. Dat geeft ze juist een voordeel en versterkt hun positie onder het motto "privacy".

Dit soort bedrijven gaan echt niet hun eigen glazen ingooien. Ik ben benieuwder hoe Google zijn tracking gaat doen dan hoe dit precies werkt.

[m4ikel]

De sessie zal wel via een server van Google lopen, dan weten ze in ieder geval exact welke accounts je hebt lopen, wanneer je inlogt en wat je zoal bezoekt (niet dat dat nu al niet kan). Kun je als webbeheerder voor die API mooi via Google Cloud betalen (want traffic). Nee, ik blijf bij Firefox, ondanks alle tegenwerkingen van Google (ingebouwde Youtube delays (its a feature, not a bug)).

[Reactie gewijzigd door m4ikel op 22 juli 2024 16:13]

[k995]

Staat op GitHub kijk gerust.

Ik weet dat de standaard instelling hier bij hoogle is absoluut negatief maar in vele gevallen is dat niet nodig .

[FvdM]

Zoals ik het artikel begrijp (misschien zit ik er naast) wordt het hierdoor eenvoudiger voor Google en adverteerders om gebruikers (devices) te volgen. Het lijkt een soort client certificate die ipv preinstalled pas na de authenticatie wordt gegenereerd. Hiermee worden alle client requests versleuteld met een eigen unieke private key en ontstaat er dus een soort persistent cookie die deel uitmaakt van de requests zelf ipv dat het een component is dat wordt meegestuurd. Buiten het bereik van privacy filters/extensions.

Edit 15:43:
Ik zit er naast, Google is nog niet zó evil als ik dacht (ik speel teveel Watch_Dogs).

Het werkt wel met cookies, maar ipv dat de website de cookies uitwisselt gaat het via een speciale endpoint. De website vraagt aan de securesession endpoint of er een session is en van wie, om daar vervolgens de interactie met de client op aan te passen. De session management zelf gebeurt dus buiten de website om; de client wisselt de tokens rechtstreeks met de securesession endpoint uit. Het lijkt daarmee meer of de refresh-token in OAuth2 bij een externe auth provider. Maar dan met kortere TTL. Als een site wordt gehackt dan heeft de aanvaller geen toegang tot de session cookies, omdat die (waarschijnlijk) via een andere hostname gaan en gebaseerd zijn op de private key van de client ipv server generated.

DBSC instead allows a website to consolidate the session binding to a few points: At sign-in, it informs the browser that a session starts, which triggers the key creation. It then instructs the browser that any time a request is made while that session is active, the browser should ensure the presence of certain cookies. The browser does this by calling a dedicated refresh endpoint (specified by the website) whenever such cookies are needed, presenting that endpoint with a proof of possession of the private key. That endpoint in turn, using existing standard Set-Cookie headers, provides the browser with short-term cookies needed to make other requests.

[Reactie gewijzigd door FvdM op 22 juli 2024 16:13]

[AltijdHetzelfde]

Daarnaast gebruikt de DBSC-sleutel de TPM 2.0-microchip van een pc, waardoor malafide progamma de sleutels moeilijker kan stelen.

Iedereen probeert maar zoveel mogelijk ewaste te maken.

Het bedrijf overweegt softwarematige alternatieven voor gebruikers zonder TPM 2.0-microchip.

Dus eigenlijk cookies maar dan een andere naam. Want dat valt allemaal te spoofen.

Ik denk persoonlijk nog steeds veiliger af te zijn met iedere website in zijn eigen container te gooien met "Firefox Multi-Account Containers" en iedere site in zijn eigen container.

[ChemoNL]

Daarmee voorkom je nog altijd niet het "Cookie stelen" probleem. het isoleert alleen het 1 en ander

[AltijdHetzelfde]

Ik zie niet in hoe de softwarematige oplossing van google met deze nieuwe techniek het probleem voorkomt. Het klinkt als meer van hetzelfde onder een andere naam, allemaal onder het mom van het beste voor de eindgebruiker; Terwijl het eigenlijk het beste is voor de grootste advertentieboer: Google.

[The Zep Man]

Ik zie niet in hoe de softwarematige oplossing van google met deze nieuwe techniek het probleem voorkomt.

Soms zijn browsers in user mode gecompromitteerd, maar is het systeem zelf niet gecompromitteerd. Als je de user mode-applicatie regelmatig een sign verzoek laat doen naar iets wat op een hoger niveau draait en het hogere niveau is niet gecompromitteerd, dan kan de sessie niet zomaar volledig overgenomen worden op een ander apparaat. Goede beveiliging bestaat uit lagen, en een softwarematige scheiding is beter dan niets.

Overigens een beetje gemixte gevoelens hierover, gezien Google maar al te graag meer controle wil over clientapparaten. Zie het vorige (afgeschoten) voorstel voor Web Environment Integrity, waarmee webcontent de mogelijkheid zou krijgen om beschermd te worden door hardwarematige DRM. Dit was geschreven in het voordeel van Google, niet in het voordeel van de gebruiker (zoals hier goed wordt samengevat).

Nu komt er nog een softwareoplossing als alternatief voor authenticatiecookies, maar kunnen websites afdwingen dat hardware wordt gebruikt? Hardware die potentieel enkel door Chrome wordt ondersteund en die niet eens beschikbaar is in bepaalde apparaten?

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:13]

[BRAINLESS01]

In dit geval kan Google wel eens gelijk hebben. Ik heb niet naar de implementatie gekeken, maar als het een beetje werkt zoals SSL/HTTPS is dat heel goed. Bij HTTPS kun jij verifiëren dat je met de juiste server praat, zonder dat je daarvoor vooraf gegevens hoeft te delen. Als voor deze "cookies" ook een vorm van encryptie gebruikt wordt kan de server dat straks ook andersom doen.

Bij de huidige cookies is het letterlijk zo dat ik jouw sessie over kan nemen door alleen jouw cookie in mijn browser op te slaan. In het verleden werd dat misbruikt doordat websites manieren vonden om cookies van een andere site uit te lezen, maar virussen of andere kwaadaardige software kunnen ook prima jouw cookies verzamelen. Je zal het in principe ook nooit merken als iemand jouw cookie gebruikt, het is immers jouw gebruikerssessie - de hacker hoeft dus niet eens in te loggen.

Als je bij de nieuwe implementatie de TPM2 chip fysiek uit de computer moet halen om een sessie over te nemen gaat het wel een keer opvallen

[bzzzt]

[...]
Iedereen probeert maar zoveel mogelijk ewaste te maken.

Lekker overdreven, TPM 2 bestaat sinds 2015 en praktisch iedere PC heeft het al jaren.
Wanneer je strikte eisen stelt aan beveiliging zal je af en toe eens betere hardware moeten vereisen. Je kan die oude hardware nog prima gebruiken, maar niet wanneer er belangrijke zaken op het spel staan. Het doel is niet om ewaste te maken, maar te voorkomen dat iemand er met de inhoud van je bankrekening vandoor gaat.

[The Zep Man]

Lekker overdreven, TPM 2 bestaat sinds 2015 en praktisch iedere PC heeft het al jaren.

Mijn PC gebouwd in 2018 heeft het niet. Mijn ARM-gebaseerde PC die een stuk jonger is heeft het niet.

Verder gebruik ik nog PC's uit 2011 en ouder voor dagelijkse desktoptaken (inclusief browsen). Dat vervangen is ook e-waste.

Welke alternatieven zijn al verkend? Bijvoorbeeld: authenticeer de sessie opnieuw bij gebruik van een verdacht IP-adres (zoals wanneer de geografische locatie tussen gebruikte IP's plots te veel verschilt).

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:13]

[bzzzt]

[...]
Mijn PC gebouwd in 2018 heeft het niet. Mijn ARM-gebaseerde PC die een stuk jonger is heeft het niet.

Jammer dat je dan kennelijk een moederbord hebt gekocht van een leverancier die duidelijk zo in de kosten heeft lopen snijden dat de toekomstvastheid er onder lijdt. Sommige PCs zijn voorzien van een header waar je achteraf nog een TPM 2 unit op kan drukken.
Veel ARM systemen hebben hun eigen implementatie ('trustzone' of 'secure enclave') dus is er geen enkele reden dat het concept daarop niet zou kunnen werken.

Verder gebruik ik nog PC's uit 2011 en ouder voor dagelijkse desktoptaken (inclusief browsen). Dat vervangen is ook e-waste.

Alleen al vanwege betere stroomverbruik en betrouwbaarheid is dat vervangen ook een keer nodig.

Welke alternatieven zijn al verkend? Bijvoorbeeld: authenticeer de sessie opnieuw bij gebruik van een verdacht IP-adres (zoals wanneer de geografische locatie tussen gebruikte IP's plots te veel verschilt).

IP adressen zijn geen betrouwbare coordinaten en kunnen ook van een botnet of VPN komen. Daardoor is het lastig met een strikte definitie voor 'verdacht IP adres' te komen.

[The Zep Man]

Sommige PCs zijn voorzien van een header waar je achteraf nog een TPM 2 unit op kan drukken.

Zo'n header heeft dit moederbord, maar hoe weet ik (als particulier die er maar één nodig heeft) wat ik koop dat dat vertrouwd is? Wie biedt die garantie (en is in staat om bewust die garantie te geven)?

Alleen al vanwege betere stroomverbruik en betrouwbaarheid is dat vervangen ook een keer nodig.

Ik gebruik een notebook uit 2011 die qua energieverbruik verwaarloosbaar is t.o.v. de energie en grondstoffen die nodig zijn om een nieuwe notebook te fabriceren.

Veel ARM systemen hebben hun eigen implementatie ('trustzone' of 'secure enclave') dus is er geen enkele reden dat het concept daarop niet zou kunnen werken.

Niet alle ARM-systemen. En systemen die nu bestaan, bestaan nu. Verder mist (mainline, FOSS) Linux-ondersteuning voor alledaagse toepassingen.

Minder e-waste is belangrijker dan company profitz over de ruggen van klanten en de maatschappij.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:13]

[bzzzt]

Zo'n header heeft dit moederbord, maar hoe weet ik (als particulier die er maar één nodig heeft) wat ik koop dat dat vertrouwd is? Wie biedt die garantie (en is in staat om bewust die garantie te geven)?

Meestal worden die modules geleverd via dezelfde leveranciers die je ook al vertrouwt om een TPM 2 compatible moederbord in de handel te brengen. Als je Asus, Gigabyte of Intel niet vertrouwt moet je geen computeronderdelen bij ze bestellen.

Minder e-waste is belangrijker dan company profitz over de ruggen van klanten en de maatschappij.

Minder e-waste is een prima doel. Excessief energie steken in systemen die grotendeels over hun technische en economische levensduur heen zijn is dat niet.
Ook het missen van degelijke security features gaat over de rug van de klanten.

[The Zep Man]

Meestal worden die modules geleverd via dezelfde leveranciers die je ook al vertrouwt om een TPM 2 compatible moederbord in de handel te brengen.

Meestal, maar hoe kan ik dat als particuliere sterveling verifiëren?

Ook het missen van degelijke security features gaat over de rug van de klanten.

Niet als er alternatieven zijn (of gewoon zaken die klanten zelf maar moeten accepteren als onderdeel van hun eigen beveiliging).

Sinds Google Web Environment Integrity voorstelde verdienen ze geen enkel vertrouwen meer qua voorstellen van webstandaarden.

[bzzzt]

[...]
Meestal, maar hoe kan ik dat als particuliere sterveling verifiëren?

Je hebt toch zelf een PC of moederbord gekocht? Als je de leverancier niet vertrouwt moet je een andere zoeken.
Als je echt paranoia bent kan je proberen de details van de security implementatie op te zoeken en te begrijpen.

Niet als er alternatieven zijn (of gewoon zaken die klanten zelf maar moeten accepteren als onderdeel van hun eigen beveiliging).

Hoe kan je accepteren dat je systeem gehacked en je bankrekening geplunderd wordt?
(en nee, niet internetbankieren is tegenwoordig geen goed antwoord meer)

[The Zep Man]

Hoe kan je accepteren dat je systeem gehacked en je bankrekening geplunderd wordt?

Dat doe ik niet, maar daarom neem ik ook verantwoording over mijn informatiebeveiliging.

[bzzzt]

Door een security-technisch achterhaald systeem te gebruiken?

[The Zep Man]

Door zelf maatregelen te treffen die slachtofferschap voorkomen en niet (enkel) te vertrouwen op het werk van commerciële, beursgenoteerde bedrijven.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:13]

[bzzzt]

Het een hoeft het ander niet uit te sluiten, maar het moet je toch opgevallen zijn dat computers voor eindgebruikers de laatste 40 jaar doorgaans gemaakt worden door commerciële, beursgenoteerde bedrijven?

[The Zep Man]

Wat de reden is dat ik "(enkel)" schrijf.

[latka]

Die ip databases lopen hopeloos achter. In mijn geval ongeveer 60km. Ook met mobile en cgnat werkt geoip voor geen meter

[The Zep Man]

We praten hier over een wereldwijd probleem. Niet een probleem dat zich met name in een straal van 60 km afspeelt. Verder hoeven maatregelen niet perfect te zijn, maar moeten ze goed genoeg zijn.

Ook met mobile en cgnat werkt geoip voor geen meter

Daar zou je als site verzwaarde maatregelen voor kunnen introduceren (zoals geen sessies die open blijven staan). Laat mensen maar klagen bij hun ISP's.

[latka]

Magic carpet detectie (zo noemden we dat in 2006) werkte toen alleen indicatief als in: ja het is een alarmbel maar niet genoeg om sessie af te sluiten. Is dat inzicht inmiddels veranderd? Zover ik kan nagaan namelijk niet.

[Caelorum]

Naast dat het ip ook gespoofed kan worden.
+ ip detectie met VPN werkt ook voor geen meter.

[Reactie gewijzigd door Caelorum op 22 juli 2024 16:13]

[The Zep Man]

Naast dat het ip ook gespoofed kan worden.
+ ip detectie met VPN werkt ook voor geen meter.

Dat is geen spoofen, maar simpelweg een andere exit-IP gebruiken. De IP-adressen van VPN-endpoints zijn gewoon bekend. Zie hoe streamingdiensten dat doen.

[Caelorum]

Ik zeg ook nergens dat het dezelfde dingen zijn toch?

[Emunator]

Als ze via malware op jouw pc een cookie weten te bemachtigen, kunnen ze via die malware ook vast een proxy of VPN installeren en dus gewoon jouw IP-adres gebruiken.

[Martinspire]

Die PC is ook alweer 6 jaar oud. Niet bepaald een nieuw beestje. Mijn PC heeft ook niet de laatste bluetooth, op een gegeven moment zul je over moeten als dat voordelen oplevert. In dit geval dus betere beveiliging (zo vind Google zelf)

[Anoniem: 57411]

Ik denk persoonlijk nog steeds veiliger af te zijn met iedere website in zijn eigen container te gooien met "Firefox Multi-Account Containers" en iedere site in zijn eigen container.

Volgens mij helpt dat niet met het verhelpen van het probleem dat aangepakt zou worden met de koekjes-vervanger; dat de koekjes via een aanval, die niet per se via de browser loopt, worden bemachtigd.

[LOTG]

Dus een hardware implementatie is niet goed want e-waste om dat sommige mensen nog geen TPM hebben, maar een software implementatie is ook niet goed want minder veilig.

Wat wil je dan nu?

Die Firefox containers zijn net zo min een oplossing voor dit probleem.

[JacOwns7]

Even voor mijn beeld. Hoe loopt men zo'n session stealer op?
Beetje op de zelfde manier als Mal/Ransomware door gare content van gare sites te downloaden?
Brakke malafide plugins?
Is dit dan niet een beetje overtrokken als je al gebruik maakt van Common Sense antivirus

[Martijn.C.V]

Stukje javascript is voldoende.
1. Verzin een manier om de user jouw JS te laten uitvoeren (alsof het door de site zelf uitgevoerd wordt)
2. Lees de cookies en verstuur ze naar jouw-website.nl?cookie={hier de data die je wilt}
3. Lees de logs uit op je site, of iets met php etc.
4. Ga nu weer naar je targetsite en stuur je gestolen cookie mee. Zeker het cookie sessie waardes zijn waardevol, je bent door dat mee te sturen nu dat persoon.


Real world vergelijking:
- Scoor een kopie van iemand ID-kaart
- Toon deze bij waar je je moet authenticeren (zonder je gezicht te laten zien). Je bent nu binnen als dat persoon.

Wat Google gaat toevoegen is dat je naast je cookie ook een key van jouw machine moet laten zien. Vergelijkbaar met dat je jouw 'key', eg gezicht, bij het ID moet laten zien.

[Reactie gewijzigd door Martijn.C.V op 22 juli 2024 16:13]

[JacOwns7]

Helder, dank voor de toelichting.
Als ik het dus goed begrijp zal er in ieder geval een stukje social enginering bij moeten komen kijken?
Of kan dit automagisch door bijv de eerder genoemde malafide site?

[Martijn.C.V]

Het hoeft niet social enginering te zijn. De harde voorwaarde is dat de JS wordt uitgevoerd alsof de site dat zelf uitvoert. Een redelijk complex voorbeeld is bijvoorbeeld:

De hacker wilt graag jouw sessie-cookie van voorbeeld.com. Hacker maakt een plugin welke alle requests onderschept, maar daar iets mee doen zou verdacht zijn! Dus het enige wat deze plugin doet is wachten tot voorbeeld.nl/code.js wordt opgevraagd en plakt daar, vlak voordat ie t weer doorgeeft aan je browser, een klein stukje eigen code aan toe!

Dat is wel wat simplistisch en slechts een enkel voorbeeld. Het moeilijke stukje in het voorbeeld hierboven is jou overhalen dat die specifiek die (onbekende) plugin echt wilt hebben.

[JacOwns7]

In dit voorbeeld bedoel ik maar. Iemand zou je toch moeten overhalen dat je deze plugin wil installeren. Vandaar ook mijn opmerking van Common Sense AV

[svane]

Gelukkig is het wel iets minder makkelijk dan je nu schetst

1. Verzin een manier om de user jouw JS te laten uitvoeren (niet bijzonder lastig)

dat stukje code moet wel uitgevoerd worden door JS op de website waarvan je de cookies wil stelen. Tweakers.net voert aardig wat JS uit, maar krijgt de cookies van gmail.com mooi niet te zien!
Je zal iets als een XSS kwetsbaarheid moeten vinden. Afhankelijk van je doelwit kan dit wel bijzonder lastig zijn.

2. Lees de cookies en verstuur ze naar jouw-website.nl?cookie={hier de data die je wilt}

Alleen cookies die niet http-only zijn, kan je uitlezen via javascript. Daarom is het ook geen slim idee om geheime informatie in cookies te stoppen die niet http-only zijn, dit wordt ook afgeraden.

De rest van het verhaal klopt, heb je iemands cookies, dan heb je meestal ook toegang tot iemands account!