Google sta rendendo molto più difficile il riutilizzo dei cookie di sessione rubati grazie a Device Bound Session Credentials (DBSC), una tecnologia che lega crittograficamente la sessione al dispositivo su cui è stato effettuato l’accesso.
La funzione è generalmente disponibile su Windows con Chrome 146 e Google ha già avviato l’espansione verso macOS, rendendo i cookie di sessione praticamente inutilizzabili se copiati su un’altra macchina.
Perché i cookie rubati sono un problema
I cookie di sessione sono file che i siti web usano per ricordare che un utente ha già effettuato il login, evitando di chiedere password o secondo fattore a ogni pagina. Gli infostealer, malware specializzati nel raccogliere dati dai browser, possono copiare questi cookie e permettere a un aggressore di accedere all’account da un altro dispositivo senza dover superare l’autenticazione iniziale. Anche con password robuste e MFA attivo, il furto di sessione avviene dopo il login, sfruttando un token già autorizzato che resta valido per ore o giorni.
DBSC introduce una coppia di chiavi crittografiche associata alla sessione: la chiave privata viene generata e conservata in un componente sicuro del dispositivo, come il TPM su Windows o il Secure Enclave su macOS, e non può essere esportata. Il server memorizza invece la chiave pubblica e, quando il cookie di sessione deve essere rinnovato, chiede a Chrome di dimostrare il possesso della chiave privata tramite una prova crittografica. Un cookie copiato su un’altra macchina non supera questa verifica perché manca della chiave privata originale, rendendo la sessione rubata rapidamente inutilizzabile.
Cookie più brevi e rinnovo controllato
Il protocollo non elimina i cookie tradizionali, ma li rende di breve durata (ad esempio 10 minuti) e rinnovabili solo se Chrome prova di essere ancora sul dispositivo originale.
Il browser gestisce in modo trasparente la rotazione delle sessioni, mentre il sito continua a usare cookie standard per rappresentare l’accesso autenticato, aggiungendo solo endpoint dedicati per registrare e verificare la credenziale legata al dispositivo. Ogni sessione utilizza una chiave specifica, impedendo ai siti di correlare automaticamente attività diverse dello stesso utente e preservando la privacy.
L’autenticazione a più fattori e le passkey proteggono bene il momento del login, ma non impediscono automaticamente a un malware già presente sul computer di leggere i token creati dopo l’accesso. DBSC aggiunge un livello successivo: dopo aver dimostrato chi è l’utente, il servizio può verificare anche se la sessione continua a essere utilizzata dal dispositivo che l’ha originata. Questo non rende inutili MFA e passkey, ma riduce drasticamente il valore operativo di un cookie rubato, costringendo l’attaccante a operare localmente sulla macchina compromessa invece che da remoto.
Disponibilità e adozione lato server
DBSC è attivo di default per gli utenti Google Workspace in ambiente Windows da maggio 2026 e Google lo sta estendendo gradualmente anche agli account personali.
La protezione però non è automatica per tutti i siti: il servizio web deve implementare il supporto lato server e partecipare al protocollo DBSC, aggiungendo gli endpoint necessari per registrare e verificare la credenziale legata al dispositivo. Google ha già integrato il meccanismo nei propri servizi, mentre altri fornitori devono adottarlo autonomamente; il protocollo è stato sviluppato come progetto aperto nel mondo Chromium e sta essendo formalizzato dal W3C.