Le Device Bound Session Credentials (DBSC) spiegate

Whitepaper Passkey enterprise. Guide pratiche, pattern di distribuzione e KPI per programmi passkey.

Ottieni il whitepaper

Stato di supporto dei browser

Legenda: ✅ Generalmente disponibile | 🚧 Annunciato / in sviluppo | ⏸️ Trial concluso | 🔄 In valutazione/monitoraggio | ❌ Non ancora disponibile

Nota: DBSC è in GA su Windows con TPM a partire da Chrome 146 (aprile 2026). Il supporto per macOS tramite Secure Enclave sarà distribuito prossimamente. La roadmap dichiarata da Google include anche chiavi basate su software per estendere la protezione ai dispositivi senza hardware sicuro dedicato.

Vantaggi principali: DBSC vs modello attuale

L'architettura del World Wide Web si fondava su un principio di assenza di stato. Quando l'HTTP è stato inizialmente progettato, non conservava informazioni sugli utenti tra una richiesta e l'altra. Per risolvere questo problema, è stato inventato il "cookie", un piccolo dato inviato da un sito web e memorizzato sul computer dell'utente, per essere rispedito al sito web a ogni richiesta successiva. Per decenni, questo meccanismo è servito come base per la gestione delle sessioni. Quando un utente effettua l'accesso, il server convalida le sue credenziali ed emette un cookie. Questo cookie funge da "token bearer". Nel mondo fisico, uno strumento al portatore è un documento che dà diritto al titolare ai diritti o ai beni che rappresenta; se possiedi l'obbligazione, possiedi l'obbligazione. Allo stesso modo, nel mondo digitale dell'HTTP, se possiedi il cookie, sei l'utente.

Questa capacità del portatore è contemporaneamente la più grande utilità del web e la sua più profonda vulnerabilità. La sicurezza dell'intera sessione, e per estensione, l'identità dell'utente, i dati e gli asset finanziari, poggia interamente sulla segretezza di quella stringa del cookie. Se un malintenzionato riesce a copiare quella stringa, può impersonare l'utente da qualsiasi dispositivo, ovunque nel mondo, aggirando completamente i controlli di autenticazione iniziali. Questa specifica vulnerabilità ha dato origine a un'economia sommersa su scala industriale di furto di cookie e dirottamento di sessione.

Mentre il settore rafforza con successo la "porta d'ingresso" dell'autenticazione attraverso l'adozione degli standard FIDO (Fast Identity Online) e delle passkey, gli aggressori stanno spostando la loro attenzione sulla "porta sul retro": la sessione attiva. Eseguire il phishing di una password sta diventando più difficile, ma rubare un cookie di sessione rimane pericolosamente efficace. La risposta del settore a questa minaccia crescente sono le Device Bound Session Credentials (DBSC).

Le DBSC rappresentano un cambio di paradigma nel modo in cui vengono mantenute le sessioni web. Propongono di passare dai semplici token bearer a un modello in cui la sessione è crittograficamente legata al dispositivo. Con Chrome 146 (aprile 2026) che rende disponibile DBSC in GA su Windows, lo standard è passato da sperimentale a una capacità di produzione che i team web possono implementare oggi. Chrome utilizza i TPM su Windows e sta introducendo il supporto per la Secure Enclave su macOS prossimamente; le specifiche stesse sono agnostiche in merito alla memorizzazione delle chiavi, richiedendo solo che sia "robusta contro la minaccia descritta". Questo rende i cookie rubati molto meno preziosi. Non possono essere aggiornati da un altro dispositivo senza la chiave vincolata.

Questo articolo fornisce un'analisi esaustiva di DBSC, progettata per architetti della sicurezza, product manager e sviluppatori. Esplora l'architettura tecnica, le implicazioni aziendali della "sicurezza senza attriti", il rapporto con gli standard emergenti come Shared Signals (CAEP/RISC) e come le organizzazioni possono prepararsi a questo futuro utilizzando piattaforme come Corbado.

Domande chiave a cui risponde questo articolo

1. Perché l'attuale gestione delle sessioni non riesce a prevenire i takeover dell'account?
2. In che modo DBSC è diverso dai cookie "Secure" esistenti e dai flag HttpOnly?
3. Come lavorano insieme DBSC e passkey per una maggiore resistenza al phishing?
4. Cosa è successo al Token Binding e perché DBSC sta avendo successo dove l'altro ha fallito?
5. Quali sono le implicazioni aziendali e il ROI per i Product Manager?
6. Quali browser e sistemi operativi supportano DBSC oggi?
7. Come possono le organizzazioni implementare DBSC senza partire da zero?
8. Qual è la relazione tra DBSC, DPoP e OAuth 2.0?
9. In che modo DBSC si integra con Shared Signals (CAEP/RISC) per la risposta alle minacce in tempo reale?

Per navigare nella complessità di questo nuovo standard, dobbiamo prima capire i problemi fondamentali con l'attuale gestione delle sessioni e come DBSC fornisce le soluzioni. Ciascuna di queste aree rappresenta una vulnerabilità o limitazione critica che DBSC affronta.

Il fallimento fondamentale dell'attuale gestione delle sessioni è la "portabilità" della fiducia. Quando un server emette un cookie di sessione, sta essenzialmente emettendo un passaporto che funziona per chiunque lo possieda. Sebbene i browser abbiano implementato difese come i flag HttpOnly e Secure (impedendo l'accesso JavaScript e garantendo la trasmissione tramite HTTPS), queste difese proteggono solo contro vettori di estrazione specifici come il Cross-Site Scripting (XSS) o lo sniffing della rete. Non offrono alcuna protezione contro il malware in esecuzione sul dispositivo host. Gli "infostealer" sono malware specificamente progettati per localizzare il file di archiviazione dei cookie del browser sul disco, decrittografarlo (spesso utilizzando le credenziali a livello di sistema operativo dell'utente stesso) ed esfiltrare i contenuti verso un server di comando e controllo. Una volta che l'attaccante possiede il cookie, può eseguire un attacco Pass-the-Cookie, iniettando il token rubato nel proprio browser per dirottare la sessione. Il server, vedendo un cookie valido, presume che la richiesta sia legittima.

DBSC introduce un secondo fattore di autenticazione nel ciclo di mantenimento della sessione stesso. A differenza di un normale cookie sicuro, che è un segreto statico, una sessione DBSC è composta da un token bearer di breve durata e da una prova crittografica di possesso. Il browser genera una coppia di chiavi pubblica-privata archiviata in modo sicuro sul dispositivo. Il server associa la sessione alla chiave pubblica. Periodicamente, il browser deve dimostrare di possedere ancora la chiave privata firmando una challenge dal server. La specifica richiede un'archiviazione delle chiavi "robusta contro la minaccia descritta". Chrome usa il TPM su Windows quando disponibile. Se un attaccante ruba il cookie da un dispositivo diverso, non può aggiornarlo perché non può generare la firma crittografica richiesta. L'aspetto "bearer" è ridotto a una finestra temporale molto breve, mentre l'aspetto di "vincolo" fornisce continuità a lungo termine.

Passkey e DBSC sono tecnologie complementari che proteggono diverse fasi del ciclo di vita dell'utente. Le passkey (FIDO2) risolvono il problema dell'autenticazione dimostrando l'identità per avviare una sessione senza password, eliminando così il phishing delle credenziali. DBSC affronta il problema post-autenticazione rendendo il dirottamento della sessione tramite il furto di cookie significativamente più difficile. L'Alleanza FIDO inquadra DBSC come una tecnologia complementare che "alza l'asticella" contro il dirottamento della sessione. Insieme, riducono la superficie di attacco attraverso il ciclo di vita dell'accesso e della sessione, sebbene DBSC non protegga dai malware con accesso continuo al dispositivo o da attacchi browser-in-the-middle in tempo reale sullo stesso dispositivo.

Come funzionano insieme le passkey e DBSC

DBSC non è il primo tentativo di risolvere questo problema. Il "Token Binding" è stato uno standard precedente che ha tentato di vincolare i cookie alla connessione TLS (Transport Layer Security) sottostante. Pur essendo crittograficamente solido, il Token Binding non ha ottenuto adozione a causa della sua forte dipendenza dal livello TLS. Nel web moderno, le connessioni TLS vengono spesso terminate presso i bilanciatori di carico, le CDN o i reverse proxy, mentre la logica dell'applicazione risiede sui server dietro di essi. Propagare le informazioni del Token Binding attraverso questi complessi livelli di rete si è rivelato troppo difficile. DBSC impara da questo fallimento operando interamente a livello di applicazione (HTTP). Non dipende dalla connessione di rete sottostante, rendendolo compatibile con i bilanciatori di carico, i proxy e le infrastrutture cloud esistenti.

Per i leader di prodotto, DBSC offre un'opportunità per migliorare la sicurezza e contemporaneamente migliorare l'esperienza utente (UX). Tradizionalmente, un'elevata sicurezza significava brevi timeout di sessione, costringendo gli utenti ad accedere frequentemente (attrito). Vincolando la sessione al dispositivo, il rischio di furto remoto dei cookie si riduce notevolmente. Le aziende possono prendere in considerazione durate della sessione più lunghe, sapendo che i cookie rubati non possono essere aggiornati da un altro dispositivo. Tuttavia, DBSC non protegge dal furto del dispositivo, da malware persistenti sul dispositivo o da abusi da parte di un utente malintenzionato, quindi le policy sulla durata della sessione dovrebbero comunque riflettere questi rischi residui.

Per comprendere l'urgenza dietro DBSC, si deve apprezzare la sofisticazione del panorama moderno delle minacce. Il furto dei cookie di sessione è passato dall'essere un trucco per hacker di nicchia a un'industria scalabile e automatizzata.

graph TD
    A[L'utente scarica<br/>software dannoso] -->|Esecuzione| B[L'infostealer si attiva<br/>sul dispositivo]
    B --> C[Individua i dati del browser]
    C --> D[Archiviazione dei cookie<br/>Chrome/Edge/Firefox]
    C --> E[Database delle password]
    C --> F[Wallet crypto]

    D --> G[Decrittografa utilizzando<br/>credenziali del sistema operativo]
    E --> G
    F --> G

    G --> H[Crea un file di log<br/>con i dati rubati]
    H --> I[Esfiltra verso il server C2]
    I --> J[Mercato del dark web]

    J --> K[L'attaccante acquista il log]
    K --> L[Importa il cookie nel<br/>proprio browser]
    L --> M[Bypassa l'MFA]
    M --> N[Acquisizione dell'account<br/>completata]

    style A fill:#ff6b6b,color:#fff
    style B fill:#ff6b6b,color:#fff
    style N fill:#ff6b6b,color:#fff
    style J fill:#495057,color:#fff
    style M fill:#ffd43b,color:#000

Il Malware-as-a-Service (MaaS) ha abbassato la barriera d'ingresso per i criminali informatici. Gli "infostealer" come RedLine, Raccoon, Vidar e Taurus sono ceppi di malware disponibili in commercio progettati con un obiettivo principale: l'esfiltrazione dei dati dai browser web. Questi stealer vengono distribuiti tramite e-mail di phishing, software crackato o annunci dannosi. Una volta installati, prendono di mira i percorsi file specifici in cui i browser come Chrome, Edge e Firefox memorizzano i loro dati.

• L'obiettivo: Il database dei cookie (solitamente un file SQLite) e il database dei dati di accesso (password salvate).
• Il meccanismo: I browser crittografano questi database utilizzando le API di protezione dei dati (DPAPI su Windows) collegate all'accesso al sistema operativo dell'utente. Poiché il malware viene eseguito come l'utente, può banalmente richiedere la decrittografia di questi file.
• L'output: Il malware genera un "log", un file zip contenente i cookie decrittografati, le password, le informazioni di sistema e, a volte, le chiavi dei wallet di criptovalute.

Questi log vengono aggregati e venduti sui marketplace del dark web come Genesis Market (prima del suo smantellamento) e Russian Market. Gli acquirenti possono cercare log contenenti cookie attivi per specifici target di alto valore: "Salesforce", "Gmail", "Bank of America" o "AWS Console".

L'aggiramento: Il valore di un log di cookie risiede nella sua capacità di aggirare l'Autenticazione a più fattori (MFA). La maggior parte delle challenge MFA (SMS, TOTP, Push) si verifica solo durante l'evento di login. Una volta stabilita la sessione ed emesso il cookie, il server presume che l'utente sia attendibile. Un attaccante che importa un cookie di sessione valido supera facilmente il cancello MFA, apparendo al server come l'utente che ritorna su una scheda attiva.

Le suite di produttività cloud sono gli obiettivi principali. Un cookie di sessione rubato per un account Google Workspace o Microsoft Entra ID (in precedenza Azure AD) può consentire a un attaccante di accedere alle e-mail aziendali, ai documenti e ai sistemi interni. La stessa threat intelligence di Google ha segnalato un massiccio aumento dei furti di cookie come vettore primario per accedere agli Account Google, indicandolo esplicitamente come il motore del loro investimento in DBSC. Hanno notato che poiché impongono la verifica in due passaggi (2SV) e le passkey, gli attaccanti hanno semplicemente spostato le loro tattiche dal phishing delle credenziali (che 2SV / passkey fermano) al furto di cookie (che 2SV / passkey spesso non fermano).

Storicamente, i motori di rischio hanno cercato di rilevare il furto di sessione analizzando le impronte digitali (fingerprint) dei dispositivi, osservando la stringa User-Agent, la risoluzione dello schermo, i font installati e l'indirizzo IP. Se un cookie di sessione appare improvvisamente da un nuovo IP con un canvas fingerprint leggermente diverso, il server potrebbe invalidarlo. Il problema: Le iniziative sulla privacy nei browser (come l'Intelligent Tracking Prevention di Safari e il Privacy Sandbox di Chrome) stanno attivamente riducendo l'entropia di queste impronte digitali per fermare il tracciamento degli annunci. Ciò rende sempre più difficile un "buon" fingerprinting per la sicurezza. Inoltre, gli aggressori ora utilizzano "browser anti-rilevamento" che consentono loro di falsificare queste impronte digitali per farle corrispondere perfettamente al profilo della vittima, rendendo inefficace il rilevamento euristico. DBSC sostituisce questo gioco di ipotesi probabilistiche con una prova crittografica deterministica.

Le Device Bound Session Credentials (DBSC) introducono un'API e un protocollo standardizzati per la creazione di sessioni associate a una chiave sul dispositivo client. La specifica richiede che l'archiviazione della chiave sia "robusta contro la minaccia descritta", ma è agnostica in merito all'implementazione. Chrome utilizza il TPM su Windows quando disponibile. Questa sezione illustra nei dettagli la meccanica definita nel Working Draft del W3C e nella documentazione di Chrome.

Il ciclo di vita DBSC consente una transizione fluida da una sessione standard a una sessione vincolata, garantendo la retrocompatibilità e un miglioramento progressivo.

sequenceDiagram
    participant Utente
    participant Browser
    participant HSM as HSM (TPM/Secure Enclave)
    participant Server

    Note over Utente,Server: Fase 1: Autenticazione e Vincolo
    Utente->>Browser: Login con credenziali/passkey
    Browser->>Server: Richiesta di autenticazione
    Server->>Browser: Successo + intestazione di registrazione DBSC
    Browser->>HSM: Genera coppia di chiavi
    HSM->>Browser: Chiave pubblica/privata (privata non esportabile)
    Browser->>Server: Registra chiave pubblica (firmata JWT)
    Server->>Server: Vincola la sessione alla chiave pubblica
    Server->>Browser: Cookie a breve termine (5 min)

    Note over Utente,Server: Fase 2: Utilizzo normale
    loop Ogni richiesta entro 5 minuti
        Browser->>Server: Richiesta con cookie
        Server->>Browser: Risposta
    end

    Note over Utente,Server: Fase 3: Aggiornamento (dopo la scadenza)
    Browser->>Server: Richiesta con cookie scaduto
    Server->>Browser: 401 + Nonce della challenge
    Browser->>HSM: Firma challenge
    HSM->>Browser: Firma
    Browser->>Server: Prova della firma
    Server->>Server: Verifica con chiave pubblica salvata
    Server->>Browser: Nuovo cookie a breve termine
    Browser->>Server: Riprova richiesta originale
    Server->>Browser: Risposta di successo

Il processo di associazione inizia immediatamente dopo che l'utente si è autenticato utilizzando metodi standard (password, passkey, ecc.).

1. Segnale del server: Dopo aver effettuato l'accesso con successo, il server imposta un cookie di sessione (come al solito), ma aggiunge un'intestazione specifica che indica il supporto DBSC.

   HTTP
   HTTP/1.1 200 OK
   Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
   Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
   

   • L'intestazione Secure-Session-Registration indica al browser: "Supporto gli algoritmi ES256 e RS256. Registra una sessione vincolata all'endpoint /auth/dbsc/register."

2. Generazione delle chiavi: Il browser analizza questa intestazione. Genera una nuova coppia di chiavi asimmetriche (es. Elliptic Curve P-256), archiviata in modo sicuro sul dispositivo.

   • Nota sull'implementazione: Chrome utilizza il TPM su Windows quando disponibile; la specifica è agnostica rispetto al meccanismo di archiviazione, richiedendo solo che sia "robusta contro la minaccia descritta".
   • Ambito di privacy: La chiave è limitata all'origine web (es. bank.com). Il browser assicura che questa chiave non venga mai utilizzata per retailer.com, impedendo il tracciamento cross-site.

3. Richiesta di registrazione: Il browser invia una richiesta al percorso di registrazione specificato. Questa richiesta include la chiave pubblica appena generata all'interno di un JSON Web Token (JWT), firmato dalla chiave privata (attestazione autofirmata).

   HTTP
   POST /auth/dbsc/register HTTP/1.1
   Content-Type: application/jwt
   
   \<Intestazione JWT\>.\<Payload JWT contenente la chiave pubblica\>.\<Firma\>
   

4. Vincolo della sessione: Il server convalida la firma per garantire che la chiave pubblica sia funzionante. Quindi aggiorna il suo database per associare la sessione dell'utente (session_id=xyz123) a questa specifica chiave pubblica. Da questo momento in poi, la sessione è "vincolata".

Per bilanciare sicurezza e prestazioni (le operazioni sicure con le chiavi possono aggiungere latenza), DBSC utilizza un sistema a doppio token.

1. Emissione: Il server emette un nuovo cookie a breve termine (es. valido per 5 minuti). Chiamiamo questo access_token.
2. Utilizzo: Il browser utilizza questo access_token per tutte le richieste normali (recupero di immagini, chiamate API, navigazione di pagine). Finché il cookie è valido, non vengono eseguite operazioni crittografiche. Questo garantisce che la navigazione rimanga veloce.
3. Scadenza: Dopo 5 minuti, l'access_token scade.

Questo è il cuore del meccanismo di sicurezza. Quando il cookie a breve durata scade, un attaccante su un dispositivo diverso viene bloccato, ma l'utente legittimo (con accesso alla chiave vincolata) può continuare.

1. Rilevamento: Il browser tenta una richiesta. Nota che il cookie è scaduto (o il server restituisce un 401 o una specifica intestazione Secure-Session-Challenge).
2. Intercettazione: Il browser mette in pausa la richiesta di rete. Non mostra un errore all'utente.
3. Richiesta di aggiornamento: Il browser chiama automaticamente l'endpoint di aggiornamento definito nella configurazione della sessione.
   • Il server invia una challenge crittografica (un nonce).
   • Il browser utilizza la chiave vincolata per firmare questa challenge.
   • La firma prova il possesso della chiave privata.
4. Invio: Il browser invia la challenge firmata al server.

   HTTP
   POST /auth/dbsc/refresh HTTP/1.1
   Sec-Secure-Session-Id: \<ID Sessione\>
   Secure-Session-Response: \<Firma JWT della Challenge\>
   

5. Convalida: Il server utilizza la chiave pubblica memorizzata per verificare la firma.
   • Se valida: Il server sa che la richiesta proviene dallo stesso dispositivo fisico che ha avviato la sessione. Emette un nuovo access_token a breve termine (valido per altri 5 minuti).
   • Se non valida: La richiesta viene rifiutata. La sessione viene terminata.
6. Ripresa: Il browser prende il nuovo cookie e riprova in modo trasparente la richiesta originale in pausa. L'utente non subisce alcuna interruzione.

graph LR
    subgraph "Dispositivo della vittima"
        A[Sessione utente<br/>con DBSC]
        B[Chiave privata<br/>HSM/TPM]
        C[Cookie +<br/>ID Sessione]
        A --> B
        A --> C
        B -.->|Non esportabile| X[Impossibile estrarre<br/>la chiave privata]
    end

    subgraph "Scenario di attacco"
        D[Il RedLine Stealer<br/>infetta il dispositivo]
        D --> E[Ruba Cookie<br/>e ID Sessione]
        E --> F[Esporta verso<br/>l'attaccante]
    end

    subgraph "Dispositivo dell'attaccante"
        G[Importa il cookie<br/>rubato]
        H[Tenta di<br/>usare la sessione]
        I[Il server richiede<br/>l'aggiornamento DBSC]
        J[Non può firmare<br/>la challenge]
        K[Sessione negata]

        G --> H
        H --> I
        I --> J
        J --> K
    end

    C -.->|Rubato| E
    F --> G

    style D fill:#ff6b6b,color:#fff
    style K fill:#51cf66,color:#fff
    style B fill:#4c6ef5,color:#fff
    style X fill:#51cf66,color:#fff
    style J fill:#ff6b6b,color:#fff

Prendiamo il caso di un attaccante che infetta il PC dell'utente con RedLine Stealer. Ruba l'access_token e il session_id. Li importa nel proprio browser.

• Scenario A (Entro 5 minuti): L'attaccante potrebbe ottenere l'accesso per alcuni minuti finché il token a breve termine scade.
• Scenario B (Dopo la scadenza): Il browser dell'attaccante (su un dispositivo diverso) tenta di utilizzare il token. Il server lo rifiuta e richiede un aggiornamento. Il browser dell'attaccante vede le intestazioni DBSC ma non può eseguire l'aggiornamento perché non possiede la chiave privata vincolata. L'attacco fallisce.

La privacy è un obiettivo di progettazione centrale di DBSC. La specifica del W3C vieta esplicitamente l'uso di identificatori globali che potrebbero tracciare gli utenti tra i vari siti.

• Chiavi per singola origine: Il browser genera una coppia di chiavi univoca per ogni sito. google.com vede la Chiave A; amazon.com vede la Chiave B. Non c'è alcuna correlazione tra loro.
• Cancellazione dell'utente: Se l'utente cancella i cookie/dati dei siti, il browser cancella anche le chiavi DBSC associate. Questo assicura che DBSC non possa essere usato come "super-cookie" per resuscitare identità cancellate.

L'implementazione di DBSC richiede che il server mantenga lo stato relativo alle chiavi pubbliche.

• Schema del database: La tabella delle sessioni deve essere aggiornata per memorizzare la public_key e la last_challenge insieme allo user_id e a session_expiry.
• Prestazioni: L'operazione di aggiornamento comporta una verifica crittografica (ad es., verificare una firma ECDSA). Pur essendo veloce, richiede un uso più intensivo della CPU rispetto al controllo di una semplice stringa. Tuttavia, poiché gli aggiornamenti avvengono solo ogni pochi minuti (non a ogni richiesta), l'overhead è trascurabile.

Oltre alle specifiche tecniche, DBSC comporta implicazioni significative per la strategia aziendale, le roadmap di prodotto e gli assetti di conformità.

Le iniziative di sicurezza sono spesso viste come centri di costo o generatori di attrito. DBSC capovolge questa narrazione. Il seguente diagramma illustra come il vincolo al dispositivo crea una cascata di vantaggi aziendali:

• Riduzione delle frodi: Neutralizzando il vettore principale per l'Account Takeover (ATO), le aziende possono risparmiare milioni in perdite per frode.
• Costi di supporto: Il recupero dell'account è costoso. Prevenire l'hackeraggio in primo luogo riduce direttamente questo onere operativo.
• Ottimizzazione delle conversioni: Nell'e-commerce, ogni prompt di login è un potenziale punto di abbandono. DBSC consente politiche aggressive del tipo "resta collegato", abilitando il checkout istantaneo senza richieste di password.

I quadri normativi come il GDPR (Regolamento generale sulla protezione dei dati) in Europa richiedono alle organizzazioni di implementare "misure tecniche e organizzative adeguate" per garantire la sicurezza.

• Sicurezza difendibile: Man mano che DBSC diventa uno standard, sarà probabilmente interpretato come lo "stato dell'arte" per la gestione delle sessioni. In caso di violazione, dimostrare che DBSC è stato implementato può essere una potente difesa contro le accuse di negligenza.
• Standard bancari (PSD2): La direttiva sui servizi di pagamento 2 richiede l'"Autenticazione forte del cliente" (SCA). Sebbene l'SCA si concentri sull'accesso, il collegamento dinamico della sessione al dispositivo si allinea perfettamente con gli obiettivi della direttiva di vincolare l'autenticazione a importi e beneficiari specifici.

I whitepaper dell'Alleanza FIDO sottolineano il concetto di "Livelli di affidabilità" (Assurance Levels).

• Moderate Assurance: Utilizza passkey sincronizzate (come quelle del Portachiavi iCloud). Ottime per le app consumer, recuperabili, facili da usare.
• High Assurance: Richiede chiavi vincolate al dispositivo. È qui che DBSC brilla. Per le risorse aziendali (portali delle risorse umane, repository di codice) o per il settore bancario di alto valore, l'organizzazione può applicare una policy che consente l'accesso solo da sessioni vincolate a uno specifico dispositivo gestito. DBSC fornisce il meccanismo di applicazione tecnica per questa policy.

Per apprezzare appieno DBSC, dobbiamo confrontarlo con altre tecnologie che hanno tentato di risolvere problemi simili.

graph RL
    subgraph "Cookie tradizionali"
        TC1[Solo Token Bearer]
        TC2[Vulnerabile al furto]
        TC3[Sessioni lunghe = Rischio]
        TC1 --> TC2
        TC2 --> TC3
    end

    subgraph "Token Binding"
        TB1[Vincolo al livello TLS]
        TB2[❌ Fallito: Infrastruttura complessa]
        TB3[Interruzione ai Load Balancer]
        TB1 --> TB2
        TB2 --> TB3
    end

    subgraph "DPoP"
        DP1[Token Binding OAuth]
        DP2[✅ Protezione API]
        DP3[Non per sessioni browser]
        DP1 --> DP2
        DP2 --> DP3
    end

    subgraph "DBSC"
        D1[Vincolo al livello HTTP]
        D2[✅ Protezione chiave hardware]
        D3[✅ Funziona con CDN/LB]
        D4[✅ Sessioni browser]
        D1 --> D2
        D2 --> D3
        D3 --> D4
    end

    style TC2 fill:#ff6b6b,color:#fff
    style TB2 fill:#ff6b6b,color:#fff
    style D2 fill:#51cf66,color:#fff
    style D3 fill:#51cf66,color:#fff
    style D4 fill:#51cf66,color:#fff
    style DP2 fill:#51cf66,color:#fff

Come accennato, il Token Binding tentava di associare la sessione al livello TLS.

• Token Binding: Richiedeva il supporto del client, del server e di ogni passaggio intermedio (Load Balancer, TLS Terminator). Si interrompeva quando una connessione veniva terminata e ricrittografata.
• DBSC: Opera a livello di applicazione HTTP. Passa attraverso i bilanciatori di carico in modo trasparente come intestazioni/cookie standard. È molto più facile da implementare nelle moderne architetture cloud (AWS/GCP/Azure) dove il TLS viene spesso gestito dalla rete edge del provider cloud.

DPoP (RFC 9449) è lo standard per i token OAuth "sender-constrained". Associa sia gli access token che i refresh token a una chiave pubblica; aspetto fondamentale poiché i refresh token sono credenziali bearer di lunga durata. Ogni richiesta API include una prova DPoP: un JWT firmato con metodo HTTP, URL, timestamp e un identificatore univoco. Le specifiche ad alta affidabilità come FAPI 2.0 impongono token sender-constrained; DPoP è il metodo consigliato quando mTLS non è disponibile.

La differenza chiave: Le chiavi DPoP vivono nel contesto dell'applicazione. La best practice prevede l'utilizzo di API del sistema operativo per un'archiviazione non estraibile, ma questo non è obbligatorio: molte implementazioni conservano le chiavi nella memoria accessibile a JavaScript. Se un attaccante riesce a eseguire codice arbitrario (XSS, malware), può accedere alle chiavi DPoP o generare prove su richiesta. DPoP ferma il replay del token tra client diversi, ma non può proteggere un contesto browser compromesso.

DBSC sposta la prova di possesso nel browser e nell'hardware. La chiave privata risiede in un TPM o in un secure enclave che JavaScript non può leggere o esportare. Il browser gestisce il protocollo e produce firme senza esporre le chiavi al codice dell'applicazione. Anche se la web app è completamente compromessa, un attaccante non può coniare nuove prove per i cookie rubati su un'altra macchina.

Sinergia: Come osserva l'Alleanza FIDO, le passkey eliminano il phishing all'accesso, mentre DBSC/DPoP proteggono i token post-autenticazione. Un'architettura moderna combina entrambi: DPoP per le API OAuth (specialmente nell'open banking regolamentato), DBSC per le sessioni del browser. Insieme chiudono il vettore di attacco "lift and shift" sull'intero ciclo di vita della sessione.

Accorciare semplicemente la durata dei cookie (ad esempio, a 15 minuti) migliora la sicurezza ma distrugge la UX. Gli utenti sono costretti ad accedere costantemente. DBSC consente la sicurezza effettiva di un cookie di 5 minuti con l'Esperienza Utente di un cookie di 30 giorni.

%%{init: {
  "theme": "default",
  "themeVariables": {
    "actorBkg": "#ffffff",
    "actorBorder": "#000000",
    "noteBkgColor": "#f1f3f5",
    "noteTextColor": "#000000",
    "activationBkgColor": "#e0e0e0",
    "actorColours": {
      "ST": "#ff6b6b",
      "IdP": "#4c6ef5"
    }
  }
}}%%

sequenceDiagram
    participant ST as Strumenti di sicurezza<br/>(CrowdStrike, Defender)
    participant IdP as Identity Provider<br/>(Okta, Google, Azure)
    participant SP1 as Service Provider 1<br/>(Slack)
    participant SP2 as Service Provider 2<br/>(Salesforce)
    participant SP3 as Service Provider 3<br/>(App bancaria)
    participant Session as Sessione utente<br/>(Protetta da DBSC)

    Note over ST,Session: Fase di rilevamento delle minacce
    ST->>ST: Rileva malware sul<br/>dispositivo dell'utente
    ST->>IdP: Segnale RISC:<br/>"Dispositivo compromesso"

    Note over IdP,SP3: Fase di propagazione del segnale
    IdP->>SP1: Evento CAEP:<br/>"Dispositivo compromesso"
    IdP->>SP2: Evento CAEP:<br/>"Dispositivo compromesso"
    IdP->>SP3: Evento CAEP:<br/>"Dispositivo compromesso"

    Note over SP1,Session: Fase di applicazione (con DBSC)
    Session->>SP1: Prossimo tentativo di aggiornamento<br/>(entro minuti)
    SP1-->>Session: x Rifiuta firma
    Session->>SP2: Prossimo tentativo di aggiornamento
    SP2-->>Session: x Rifiuta firma
    Session->>SP3: Prossimo tentativo di aggiornamento
    SP3-->>Session: x Rifiuta firma

    Note over Session: Le sessioni possono essere terminate al prossimo tentativo di aggiornamento

Il potenziale di DBSC è amplificato quando viene combinato con il Shared Signals Framework (SSF), in particolare con il Continuous Access Evaluation Profile (CAEP) e il Risk Management (RISC). Nota: SSF/CAEP è una capacità dell'ecosistema emergente: il pattern di architettura è definito, ma la distribuzione diffusa tra i vendor è ancora in fase di maturazione.

Nel vecchio modello, se il dispositivo di un utente era compromesso, l'Identity Provider (IdP) non aveva alcun modo per dire al Service Provider (SP) di terminare la sessione immediatamente. L'SP doveva aspettare la scadenza del cookie.

Il flusso DBSC + CAEP previsto:

1. Innesco: Uno strumento di sicurezza degli endpoint (come CrowdStrike o Microsoft Defender) rileva del malware sul portatile dell'utente.
2. Segnale: Lo strumento di sicurezza invia un segnale RISC all'Identity Provider (es., Okta/Google).
3. Propagazione: L'IdP invia un evento CAEP alle app connesse: "Dispositivo compromesso".
4. Applicazione (DBSC): La volta successiva in cui il browser tenta di aggiornare il cookie a breve termine DBSC, il server rifiuta la firma e termina la sessione.
   Questo pattern di architettura consente una revoca più rapida, la latenza effettiva dipende dal periodo di aggiornamento del sito e dal fatto che abbiano implementato sia DBSC che SSF.

L'adozione di DBSC dipende dai produttori di browser. Il panorama nel 2026 è cambiato in modo sostanziale: Chrome ha spostato DBSC da Origin Trial a disponibilità generale (GA) su Windows in aprile 2026, con macOS in arrivo. Gli altri browser stanno ancora valutando.

Google è il principale promotore di DBSC e il primo browser a distribuirlo su larga scala.

• Stato (aprile 2026): Chrome 146 rende disponibile DBSC in GA su Windows, terminando la fase di Origin Trial. Il supporto per macOS, che utilizza Secure Enclave, è annunciato per una prossima versione di Chrome.
• Hardware: Windows utilizza il TPM, macOS utilizzerà la Secure Enclave. Google ha dichiarato che sta anche esplorando chiavi basate su software per estendere la protezione DBSC ai dispositivi privi di hardware sicuro dedicato.
• Roadmap: L'annuncio della GA di Google ha anche pubblicato la roadmap dei passaggi successivi:
  • Proteggere l'identità federata: associazioni DBSC cross-origin in modo che la sessione del relying party (RP) rimanga vincolata alla stessa chiave del dispositivo della sessione dell'identity provider (IdP), preservando una catena di fiducia ininterrotta attraverso l'SSO.
  • Registrazione avanzata: associare le sessioni DBSC a materiale delle chiavi attendibile preesistente come certificati mTLS o chiavi di sicurezza hardware, invece di generare una nuova chiave all'accesso.
  • Supporto più ampio per i dispositivi: chiavi basate su software per dispositivi senza TPM / Secure Enclave.
• Risultati operativi: Durante il lancio, Google segnala una "riduzione significativa dei furti di sessione" per le sessioni protette da DBSC.
• Account Google: Separatamente, Google aveva già implementato una protezione in stile DBSC per i cookie degli account Google su Chrome per Windows, controllata tramite policy aziendale. Questa protegge Gmail/Workspace ed è ora la stessa famiglia di tecnologie in GA per il web in generale.

Microsoft sta partecipando attivamente.

• Stato: Edge ha condotto un Origin Trial DBSC su Windows che si è concluso a ottobre 2025. Non è stato annunciato alcun trial sostitutivo o GA.
• Contesto Enterprise: Edge utilizza l'architettura "Primary Refresh Token" (PRT) per l'SSO di Entra/Azure AD, che è concettualmente simile a DBSC. Il PRT rimane un meccanismo specifico di Microsoft; non c'è alcun piano annunciato per unificarlo con lo standard web DBSC per siti di terze parti.

La posizione di Apple è critica per la copertura mobile.

• Stato: WebKit ha una issue sulle posizioni relative agli standard che valuta DBSC segnalando preoccupazioni su usabilità/privacy. Le note di rilascio di Safari non menzionano DBSC. Non esiste alcuna dichiarazione pubblica del tipo "implementazione attiva".
• Privacy in primo piano: La preoccupazione principale di Apple è che DBSC possa essere utilizzato per creare "super-cookie" (tracciamento non cancellabile). La specifica W3C affronta questo problema garantendo che le chiavi vengano cancellate con i dati del sito web.
• Coinvolgimento: WebKit sta partecipando al processo per lo standard, ma lo stato dell'implementazione non è chiaro, è "in discussione" piuttosto che "in sviluppo".

Mozilla ha una issue sulle posizioni relative agli standard che valuta DBSC segnalando preoccupazioni su complessità e privacy. Non c'è alcun impegno pubblico per l'implementazione una volta che lo standard si sarà stabilizzato.

Dato l'attuale supporto dell'ecosistema per DBSC e passkey, le organizzazioni dovrebbero adottare un approccio graduale all'implementazione di queste tecnologie complementari. La roadmap seguente delinea le azioni immediate e le tappe della pianificazione strategica:

1. Distribuire prima le passkey: Inizia con l'implementazione delle passkey per proteggere il livello di autenticazione. Ciò fornisce una protezione immediata contro il phishing delle credenziali ed è il prerequisito per ottenere un reale valore da DBSC.

2. Rilasciare gli endpoint di registrazione e aggiornamento DBSC: Con la GA di Chrome 146, il lavoro realistico ora è l'integrazione backend: aggiungere le intestazioni Secure-Session-Registration alle risposte di login e implementare /dbsc/register più un endpoint di aggiornamento che verifichi le challenge firmate. Il codice front-end non ha bisogno di essere modificato.

3. Implementare sessioni a breve termine con i refresh token: Se non sei ancora pronto per DBSC, adotta il pattern architetturale dei token a breve termine con meccanismi di aggiornamento. Questo prepara il tuo backend per DBSC migliorando al contempo la sicurezza sin da ora.

1. Adottare un approccio ibrido: Usa il rilevamento delle funzionalità per fornire DBSC ai browser compatibili (attualmente Chrome 146+ su Windows, prossimamente macOS Secure Enclave) pur mantenendo le opzioni di fallback. Ciò massimizza la sicurezza senza escludere gli utenti su Safari, Firefox o Edge.

2. Prepararsi per i prossimi elementi della roadmap: Google ha esplicitamente menzionato l'identità federata (associazioni SSO cross-origin), la registrazione avanzata (mTLS / chiavi hardware) e le chiavi basate su software per una copertura più ampia dei dispositivi. Se gestisci un livello SSO o IdP, inizia subito a definire l'ambito per l'associazione cross-origin.

3. Integrazione con gli Identity Provider: Se si utilizza Okta, Auth0 o IdP simili, collabora con loro per abilitare il supporto DBSC nei loro SDK. Molti hanno partecipato agli Origin Trial e stanno implementando attivamente le capacità DBSC ora che Chrome è in GA.

• Inizia con obiettivi ad alto valore: Dai la priorità a DBSC per i pannelli di amministrazione, le transazioni finanziarie e l'accesso ai dati sensibili.
• Usa soluzioni gestite: Prendi in considerazione piattaforme come Corbado che gestiscono la complessità dell'implementazione DBSC e la compatibilità tra browser.
• Misura e itera: Tieni traccia di metriche come i tentativi di dirottamento di sessione, i ticket di supporto e l'attrito dell'utente per dimostrare il ROI.
• Prepararsi per la conformità: Documenta la tua implementazione DBSC poiché diventerà probabilmente un requisito di conformità per la gestione dei dati sensibili.

Implementare DBSC da zero è un grosso sforzo ingegneristico. Richiede competenza crittografica, conoscenza approfondita delle incongruenze dei browser e una solida infrastruttura lato server per gestire chiavi e challenge. È qui che Corbado funge da abilitatore.

Non puoi costruire una sessione ad alta affidabilità su un accesso a bassa affidabilità. Se un utente accede con una password debole, la sessione è sicura solo quanto quella password. Il prodotto principale di Corbado (le passkey gestite) fornisce le fondamenta necessarie. Integrando Corbado, le organizzazioni possono distribuire facilmente le passkey, assicurando che l'inizio della sessione sia resistente al phishing.

Corbado sfrutterà DBSC per migliorare il rilevamento dei dispositivi attendibili. Quando i segnali DBSC sono disponibili, forniscono la prova crittografica che una sessione ha origine da uno specifico dispositivo, consentendo a Corbado di aumentare di conseguenza i livelli di fiducia dell'autenticazione.

• Risolvere l'ambiguità delle passkey sincronizzate: Le passkey sincronizzate sono comode ma creano una lacuna di fiducia: quando un utente si autentica con una passkey sincronizzata, non si può dire se si tratta del suo solito laptop o di un dispositivo nuovo di zecca che ha appena sincronizzato la credenziale. DBSC colma questa lacuna. Verificando se il dispositivo ha stabilito un'associazione DBSC, Corbado può confermare che il dispositivo è veramente noto e attendibile, e non solo una sincronizzazione per la prima volta.
• Maggiore fiducia per i dispositivi noti: Quando i segnali DBSC confermano che un dispositivo è già stato visto in precedenza, Corbado può prendere decisioni sui rischi in modo più sicuro: meno richieste di autenticazione step-up per gli utenti legittimi di ritorno e controlli più severi per le sessioni da dispositivi non riconosciuti.
• Complemento alla Passkey Intelligence: I segnali DBSC si integrano con il motore esistente di Passkey Intelligence di Corbado. La combinazione di autenticazione basata su passkey e vincolo del dispositivo basato su DBSC crea una catena di fiducia completa dal login all'intero ciclo di vita della sessione.

Per domande su come Corbado intenda integrare DBSC nella sua piattaforma, contatta il team.

Per i prossimi anni, il web sarà ibrido. Alcuni utenti avranno browser compatibili con DBSC (Chrome su Windows 11); altri useranno sistemi più vecchi. Gestire questa frammentazione è difficile. Il motore Passkey Intelligence di Corbado è progettato per gestire esattamente questo tipo di logica di fallback, fornendo passkey ai dispositivi compatibili e fallback agli altri. Questa stessa intelligenza si applica al vincolo di sessione, garantendo che la sicurezza sia massimizzata per ogni utente in base alle capacità del suo dispositivo.

L'era del "Token Bearer" sta volgendo al termine. L'attuale gestione delle sessioni sta fallendo in modo catastrofico: i token bearer possono essere rubati da operazioni malware su scala industriale e utilizzati da qualsiasi dispositivo, consentendo takeover degli account che aggirano persino i metodi di autenticazione più forti. Questa vulnerabilità fondamentale ha creato un'economia sommersa che vale miliardi.

Le Device Bound Session Credentials (DBSC) rappresentano la risposta emergente del settore. A differenza dei tradizionali cookie sicuri con i loro flag HttpOnly e segreti statici, DBSC aggiunge la prova crittografica di possesso tramite chiavi vincolate al dispositivo. Ciò rende i cookie rubati molto meno preziosi. Non possono essere aggiornati da un altro dispositivo. Lì dove il Token Binding è fallito richiedendo modifiche complesse a livello TLS in tutta l'infrastruttura, DBSC ha successo operando al livello applicazione HTTP, compatibile con i bilanciatori di carico e le architetture CDN esistenti. Nota: DBSC ha percorsi di fallback documentati in cui il browser ignora l'associazione (TPM non disponibile, errori di rete), quindi riduce notevolmente, ma non elimina il rischio di furto di cookie.

La sinergia tra DBSC e passkey alza significativamente l'asticella per gli aggressori lungo tutto il percorso dell'utente. Le passkey eliminano il phishing delle credenziali al momento dell'accesso, mentre DBSC rende molto più difficile il dirottamento di sessione tramite furto remoto di cookie, formando insieme il framework di identità "high assurance" previsto dall'Alleanza FIDO. Con Chrome 146 che rilascia DBSC in GA su Windows nell'aprile 2026 e il supporto di macOS Secure Enclave in arrivo successivamente, lo standard è passato dalla fase di preparazione alla fase di implementazione. La roadmap pubblicata da Google (identità federata, registrazione con mTLS / chiavi hardware, chiavi basate su software) segnala i prossimi 12 mesi di espansione.

Per i Product Manager, il business case è convincente: DBSC consente sessioni sicure "infinite" che riducono drasticamente l'attrito di accesso, abbattendo contemporaneamente le perdite per frode e i costi di supporto. Il ROI si manifesta con tassi di conversione più elevati, un numero inferiore di ticket per la reimpostazione della password e l'eliminazione degli incidenti di account takeover. Le organizzazioni che usano OAuth possono sfruttare lo stesso concetto di key-binding attraverso DPoP per i token API, mentre l'integrazione con Shared Signals (CAEP/RISC) consente di rispondere alle minacce in tempo reale, revocando istantaneamente le sessioni compromesse al successivo tentativo di aggiornamento.

L'implementazione non richiede di partire da zero. Piattaforme come Corbado forniscono l'infrastruttura per le passkey e stanno seguendo gli sviluppi di DBSC per integrare il vincolo al dispositivo man mano che il supporto dei browser matura. La specifica W3C è un Working Draft attivo, Chrome 146 è in GA su Windows ed è in fase di implementazione su macOS, e gli altri browser stanno ancora valutando lo standard.

La traiettoria è chiara: le organizzazioni che iniziano ad adottare passkey e DBSC oggi si posizioneranno meglio per il futuro passwordless e resistente al phishing. La domanda non è se implementare le sessioni vincolate al dispositivo, ma con quale rapidità è possibile distribuirle per proteggere i tuoi utenti e il tuo business. Il futuro della sicurezza web non è solo autenticato; è crittograficamente vincolato ai dispositivi di cui ci fidiamo.

Chi siamo

Corbado è la Passkey Intelligence Platform per i team CIAM che gestiscono l'autenticazione consumer su larga scala. Ti aiutiamo a vedere ciò che i log IDP e gli strumenti di analytics generici non mostrano: quali dispositivi, versioni di OS, browser e gestori di credenziali supportano i passkey, perché gli enrollment non si trasformano in login, dove il flusso WebAuthn fallisce e quando un aggiornamento di OS o browser interrompe silenziosamente il login — tutto senza sostituire Okta, Auth0, Ping, Cognito o il tuo IDP interno. Due prodotti: Corbado Observe aggiunge osservabilità per i passkey e qualsiasi altro metodo di login. Corbado Connect introduce passkey gestiti con analytics integrato (insieme al tuo IDP). VicRoads gestisce i passkey per oltre 5M di utenti con Corbado (+80 % di attivazione passkey). Parla con un esperto di Passkey →

Quando strumenti per la sicurezza degli endpoint come CrowdStrike rilevano dei malware, inviano un segnale RISC all'Identity Provider, che invia un evento CAEP "Dispositivo compromesso" alle app connesse. Al successivo tentativo di aggiornamento DBSC (entro pochi minuti), queste app rifiutano la firma della sessione e terminano l'accesso. La distribuzione di CAEP/RISC tra più vendor è ancora in fase di sviluppo.

DPoP (RFC 9449) associa gli access token e refresh token OAuth a una chiave pubblica a livello di applicazione, proteggendo principalmente le chiamate API in app native e SPA. DBSC associa i cookie di sessione del browser a chiavi TPM supportate da hardware che JavaScript non può leggere o esportare, proteggendo le sessioni lato utente anche quando l'applicazione web stessa è compromessa da XSS o malware.

Le classiche strutture di sicurezza impongono tempi di timeout brevi per le sessioni, al fine di limitare i danni in caso il cookie venga rubato e replicato da remoto. DBSC associa la capacità di aggiornamento alla chiave privata del dispositivo d'origine, perciò un cookie rubato e utilizzato da un dispositivo diverso fallisce la verifica crittografica. Le sessioni possono essere effettivamente infinite perché gli attacchi di replica remota sono neutralizzati.

DBSC neutralizza il furto di cookie come vettore primario per l'acquisizione degli account, riducendo direttamente le perdite da frode e i costi di assistenza al recupero degli account. Sessioni lunghe e sicure eliminano continue richieste di accesso, migliorando i tassi di conversione negli e-commerce e riducendo gli abbandoni. L'Alleanza FIDO propone DBSC come strumento per innalzare il livello di sicurezza, abbassando al tempo stesso l'attrito per l'utente.