In questo articolo Indice dei contenuti 2 sezioni
Rubare i cookie di sessione, fino a oggi, era uno dei modi più comodi per entrare nell’account di qualcun altro senza conoscerne la password. Chrome ha iniziato a chiudere questa porta con Device Bound Session Credentials, sigla DBSC, un meccanismo che lega la sessione in modo crittografico al dispositivo su cui è stato fatto l’accesso. La funzione è ormai disponibile su Windows con Chrome 146 e Google ha già avviato l’espansione verso macOS. Il risultato pratico è semplice da spiegare, un cookie copiato e portato su un’altra macchina diventa carta straccia.
Vale la pena capire perché quei file contano così tanto. I cookie di sessione servono ai siti per ricordare che l’utente ha già fatto il login, così da non chiedere password e secondo fattore a ogni clic. Gli infostealer, cioè i malware specializzati nel raccogliere dati dai browser, sanno benissimo dove andarli a prendere. Una volta copiati, permettono all’aggressore di entrare nell’account da un altro computer senza dover superare nulla, perché il token è già stato autorizzato e resta valido per ore o giorni. Ecco il punto scomodo, anche con una password lunghissima e l’autenticazione a più fattori attiva, il furto avviene dopo il login e quindi salta a piè pari tutte le difese messe all’ingresso.
Come funziona la chiave che non si può copiare
DBSC introduce una coppia di chiavi crittografiche legata alla singola sessione. La chiave privata viene generata e conservata in un componente sicuro del dispositivo, il TPM su Windows oppure il Secure Enclave su macOS, e non può essere esportata in nessun modo. Il server tiene solo la chiave pubblica. Quando arriva il momento di rinnovare il cookie di sessione, chiede a Chrome di dimostrare di avere ancora quella chiave privata attraverso una prova crittografica. Un cookie finito su un’altra macchina non passa la verifica, perché quella chiave lì non c’è e non si può ricostruire.
Il protocollo non manda in pensione i cookie tradizionali, li accorcia. Durata breve, per esempio 10 minuti, e rinnovo possibile solo se il browser dimostra di essere ancora sul dispositivo originale. La rotazione delle sessioni viene gestita in modo trasparente da Chrome, mentre il sito continua a lavorare con cookie standard per rappresentare l’accesso autenticato, aggiungendo soltanto gli endpoint dedicati alla registrazione e alla verifica della credenziale legata al dispositivo. C’è anche un dettaglio pensato per la privacy, ogni sessione usa una chiave diversa, quindi i siti non possono sfruttare il sistema per correlare automaticamente attività differenti della stessa persona.
Un livello che si aggiunge a MFA e passkey
L’autenticazione a più fattori e le passkey fanno bene il loro lavoro, ma lo fanno nel momento del login. Nessuna delle due impedisce a un malware già installato sul computer di leggere i token creati subito dopo l’accesso. DBSC lavora nello strato successivo, dopo aver stabilito chi è l’utente il servizio può controllare anche se quella sessione continua a essere usata dal dispositivo che l’ha generata. Non sostituisce le protezioni esistenti, ne abbassa il punto debole, perché il valore operativo di un cookie rubato crolla e l’attaccante viene costretto a muoversi localmente sulla macchina compromessa invece di agire comodamente da remoto.
Sul fronte della disponibilità, DBSC è attivo per impostazione predefinita per gli utenti Google Workspace in ambiente Windows da maggio 2026, e l’estensione agli account personali sta procedendo in modo graduale. Resta però un aspetto da tenere presente, la protezione non arriva automaticamente su tutti i siti. Serve che il servizio web implementi il supporto lato server e partecipi al protocollo, aggiungendo gli endpoint necessari a registrare e verificare la credenziale legata al dispositivo. Google ha già integrato il meccanismo nei propri servizi, gli altri fornitori devono muoversi per conto loro. Il protocollo è nato come progetto aperto nell’ecosistema Chromium e la sua formalizzazione è in corso presso il W3C.
