Google lega le sessioni di Chrome all’hardware del dispositivo
Google annuncia DBSC per Chrome, legando crittograficamente le sessioni all'hardware del dispositivo per neutralizzare il furto di cookie da infostealer come LummaC2.
Il sistema lega i cookie di sessione all’hardware del dispositivo, rendendoli inutilizzabili se rubati da malware infostealer.
Un numero difficile da ignorare: nel solo 2024, secondo il rapporto sull’epidemia di infostealer, il malware specializzato nel furto di credenziali ha compromesso 3,9 miliardi di account su 4,3 milioni di dispositivi. Milioni di persone, le loro sessioni bancarie, i loro profili aziendali, i loro accessi a servizi critici — tutto svuotato senza che le vittime cambiassero una sola password. Ieri, 9 aprile, Google ha risposto annunciando, tramite il post del Google Security Blog, che Device Bound Session Credentials (DBSC) entra in disponibilità pubblica per gli utenti Windows su Chrome 146. La promessa: rendere i cookie di sessione rubati sostanzialmente inutili, perché legati crittograficamente all’hardware del dispositivo originale. Vale la pena capire come funziona, e soprattutto perché Google lo fa adesso.
L’epidemia degli infostealer
Il furto di cookie non è una novità, ma negli ultimi anni ha raggiunto una scala industriale. Il meccanismo è brutalmente semplice: un cookie di sessione autentico, una volta rubato, consente a un attaccante di accedere all’account della vittima senza mai conoscerne la password. Come conferma Google stessa, i malware della famiglia degli infostealer — LummaC2 in testa — sono diventati sempre più sofisticati nel sottrarre queste credenziali, aggirando anche l’autenticazione a due fattori. Non serve phishing elaborato, non serve ingegneria sociale: basta infettare il dispositivo, aspirare i cookie, e accedere.
I numeri del 2024 raccontano la portata del problema in modo impietoso. I tre principali infostealer — Lumma, StealC e RedLine — hanno rappresentato da soli oltre il 75% di tutte le infezioni registrate. Tre strumenti, milioni di vittime, un mercato nero fiorente. LummaC2 in particolare si è distinto per la sua capacità di adattarsi rapidamente alle contromisure, aggiornando le proprie tecniche con una velocità che lascia poco spazio alle difese tradizionali. La domanda che si pone da sola è: come si combatte un malware che evolve più velocemente delle patch di sicurezza?
La risposta classica — migliori password, aggiornamenti frequenti, antivirus — ha mostrato i suoi limiti strutturali. Il punto debole non è la password, ma la sessione autenticata. Una volta che un utente ha fatto login, il browser conserva quella prova di identità sotto forma di cookie. E quel cookie, se sottratto, vale quanto la password stessa. Forse di più, perché non scade subito e non richiede verifica aggiuntiva. È qui che DBSC prova a inserire un cuneo.
DBSC: la scommessa di Google
L’idea alla base di DBSC è concettualmente elegante: invece di conservare una credenziale di sessione che può essere copiata e riutilizzata altrove, il browser lega quella credenziale all’hardware del dispositivo. Tecnicamente, questo avviene attraverso moduli di sicurezza basati sull’hardware — il Trusted Platform Module (TPM) su Windows, il Secure Enclave su macOS. Il protocollo consente all’agente utente di dimostrare il possesso di una chiave privata archiviata in modo sicuro, una chiave che non può essere estratta dal dispositivo. Un cookie rubato da un dispositivo con DBSC attivo sarebbe, in teoria, inutilizzabile su qualsiasi altra macchina.
Google ha iniziato a lavorare su questo protocollo ben prima dell’annuncio di ieri. Già nell’aprile 2024, il team di Chromium ne aveva annunciato la prototipazione. Nell’ottobre 2025, DBSC aveva avviato il suo secondo origin trial, con durata programmata fino all’inizio del febbraio 2026. In tutto questo periodo, secondo quanto dichiarato da Google, sono stati condotti due Origin Trials per verificare che il protocollo soddisfacesse le esigenze della comunità web più ampia. Adesso arriva la disponibilità pubblica. Il timing è interessante: con le normative europee sulla sicurezza digitale sempre più stringenti, e con il GDPR che continua a generare sanzioni miliardarie per violazioni dei dati, offrire uno strumento concreto di protezione delle sessioni non è solo una mossa tecnica. È anche una risposta preventiva a potenziali pressioni regolatorie.
Chi ci guadagna? La risposta onesta è: Google, in prima battuta. Chrome è il browser dominante a livello globale, e rafforzarne la reputazione in termini di sicurezza ha un valore commerciale diretto, specialmente in un momento in cui browser alternativi cercano di eroderne la quota di mercato. Ma c’è un secondo livello: Google gestisce servizi di autenticazione e identità digitale usati da centinaia di milioni di utenti. Ridurre il furto di sessioni protegge anche l’integrità di quegli stessi servizi. Non è beneficenza, è interesse allineato con quello degli utenti — il che non lo rende meno utile, ma rende necessario nominarlo.
La strada verso uno standard aperto
Il vero snodo di DBSC, però, non è la sua implementazione in Chrome. È cosa succede fuori da Chrome. Google dichiara che DBSC è stato progettato fin dall’inizio come standard web aperto, attraverso il processo W3C e il Web Application Security Working Group, che ha già pubblicato una prima bozza pubblica del protocollo nel 2025. Microsoft Edge ha espresso interesse ad adottarlo per proteggere i propri utenti dal furto di cookie. Se altri browser seguiranno — e il percorso W3C serve esattamente a facilitarlo — DBSC potrebbe diventare una protezione universale, indipendente dal browser scelto dall’utente.
Ma “esprimere interesse” e “implementare” sono due cose molto diverse. E uno standard che vive solo su Chrome protegge una parte degli utenti, non il web. La domanda che i regolatori potrebbero presto porre — soprattutto in Europa, dove il Digital Markets Act osserva con attenzione ogni mossa dei grandi gatekeepers — è se un meccanismo di sicurezza controllato da Google, anche se formalmente aperto, non finisca per rafforzare la dipendenza dall’infrastruttura di un singolo operatore dominante.
DBSC potrebbe rappresentare un passo concreto verso sessioni web più sicure. Ma in un mondo in cui LummaC2 si aggiorna più velocemente di quanto i browser distribuiscano patch, e in cui il mercato degli infostealer funziona come una vera industria, la domanda finale rimane aperta: chi controllerà le chiavi del nostro accesso digitale? E quando il prossimo malware troverà il modo di aggirare anche i TPM, chi risponderà?
