--- url: 'https://www.corbado.com/it/blog/device-bound-session-credentials-dbsc' title: 'Le Device Bound Session Credentials (DBSC) spiegate' description: 'Scopri come le Device Bound Session Credentials (DBSC) prevengono il furto di sessione e di cookie. Informati sullo stato di supporto dei browser e la sicurezza aziendale.' lang: 'it' author: 'Vincent Delitz' date: '2026-06-15T13:57:11.277Z' lastModified: '2026-06-17T06:04:49.453Z' keywords: 'Device Bound Session Credentials, DBSC, prevenzione dirottamento di sessione, protezione furto di cookie, associazione di sessione TPM' category: 'Authentication' --- # Le Device Bound Session Credentials (DBSC) spiegate **Stato di supporto dei browser** > **Ultimo aggiornamento (aprile 2026):** Chrome 146 rende disponibile > [DBSC in disponibilità generale (GA) su Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), > spostando la funzionalità fuori dalla fase di Origin Trial. Il supporto per macOS > (utilizzando [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)) è in arrivo in una delle > prossime versioni di Chrome. Google ha anche annunciato una roadmap pubblica per > l'identità federata (associazioni [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) > [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn)), la registrazione avanzata (mTLS / > chiavi hardware) e le chiavi basate su software per i dispositivi privi di hardware > sicuro. | Browser | Windows | macOS | Linux | Android | iOS | Stato | | ----------- | ----------------------- | ----------------------------- | ------------------ | ------------------ | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 In arrivo (Secure Enclave) | ❌ | ❌ | ❌ | [GA su Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (aprile 2026), macOS nella prossima versione | | **Edge** | ⏸️ Trial concluso | ❌ | ❌ | ❌ | ❌ | Origin Trial concluso a ottobre 2025, nessuna GA annunciata | | **Safari** | N/A | 🔄 In valutazione | N/A | N/A | 🔄 In valutazione | WebKit in discussione, nessuna implementazione annunciata | | **Firefox** | 🔄 In monitoraggio | 🔄 In monitoraggio | 🔄 In monitoraggio | 🔄 In monitoraggio | 🔄 In monitoraggio | In valutazione, nessun impegno a implementare | **Legenda:** ✅ Generalmente disponibile | 🚧 Annunciato / in sviluppo | ⏸️ Trial concluso \| 🔄 In valutazione/monitoraggio | ❌ Non ancora disponibile **Nota:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) è in GA su Windows con TPM a partire da Chrome 146 (aprile 2026). Il supporto per macOS tramite [Secure Enclave](https://www.corbado.com/glossary/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** | **Funzionalità** | **Modello attuale dei cookie** | **Modello DBSC** | | ------------------------- | -------------------------------- | --------------------------------------------------------- | | **Tipo di token** | Bearer (possesso = accesso) | Vincolato (possesso + chiave = accesso) | | **Conseguenza del furto** | Acquisizione totale dell'account | Token inutile (impossibile da aggiornare) | | **Durata della sessione** | Breve (per sicurezza) | Lunga / infinita (sicura by design) | | **Attrito utente** | Alto (accessi frequenti) | Basso (sicurezza invisibile) | | **Aggiramento MFA** | Vulnerabile (pass-the-cookie) | Resistente (dispositivo richiesto) | | **Revoca** | Lenta (attesa scadenza) | Quasi in tempo reale (fallisce al prossimo aggiornamento) | ## Key Facts - **DBSC** vincola le sessioni web a una chiave crittografica presente sul dispositivo, rendendo i cookie rubati inutili perché non possono essere aggiornati da un altro dispositivo. - Il browser memorizza una chiave privata non esportabile in un **TPM**, firmando le challenge del server ogni 5 minuti per dimostrare il possesso del dispositivo senza l'interazione dell'utente. - A differenza del **Token Binding**, che ha fallito a causa della complessità dell'infrastruttura a livello TLS, DBSC opera al livello applicazione HTTP e funziona in modo trasparente con i bilanciatori di carico e le CDN esistenti. - **Chrome 146 rende disponibile DBSC in GA su Windows (aprile 2026)**, con il supporto Secure Enclave per macOS in arrivo in una delle prossime versioni. La roadmap pubblicata da Google copre anche l'identità federata (associazioni SSO cross-origin), la registrazione avanzata (mTLS / chiavi hardware) e le chiavi basate su software per i dispositivi senza hardware sicuro. Safari e Firefox stanno ancora valutando; l'Origin Trial di Edge è terminato a ottobre 2025 senza alcun annuncio di GA. ## 1. Introduzione: Device Bound Session Credentials (DBSC) 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](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) 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](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.w3.org/TR/dbsc/). Con [Chrome 146 (aprile 2026) che rende disponibile DBSC in GA su Windows](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), 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](https://www.corbado.com/blog/device-bound-session-credentials-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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/oauth2)? 9. In che modo DBSC si integra con Shared Signals (CAEP/RISC) per la risposta alle minacce in tempo reale? ## 2. Comprendere i problemi e le soluzioni principali 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. ### 2.1 Fallimento dell'attuale gestione delle sessioni 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](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies) (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](https://www.corbado.com/glossary/malware) in esecuzione sul dispositivo host. Gli "infostealer" sono [malware](https://www.corbado.com/glossary/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](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html), iniettando il token rubato nel proprio browser per dirottare la sessione. Il server, vedendo un cookie valido, presume che la richiesta sia legittima. ### 2.2 Il vantaggio crittografico di DBSC sui tradizionali cookie sicuri DBSC introduce un secondo fattore di [autenticazione](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) 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](https://www.w3.org/TR/dbsc/) "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. ### 2.3 Sinergia tra passkey e DBSC 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](https://www.corbado.com/glossary/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](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) 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](https://www.corbado.com/glossary/malware) con accesso continuo al dispositivo o da attacchi browser-in-the-middle in tempo reale sullo stesso dispositivo. | Tecnologie | Phishing remoto | Credential Stuffing | Furto di token | | ------------------------- | --------------- | ------------------- | -------------- | | **Passkey** | ✅ | ✅ | ❌ | | **DBSC / DPoP** | ❌ | ❌ | ✅ | | **Passkey + DBSC / DPoP** | ✅ | ✅ | ✅ | **Come funzionano insieme le passkey e DBSC** | **Aspetto** | **Passkey** | **DBSC** | **Vantaggio combinato** | | ------------------------ | ---------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------- | | **Ambito** | Autenticazione (login) | Gestione della sessione | Protezione end-to-end | | **Minaccia mitigata** | Phishing di password, credential stuffing | Dirottamento remoto della sessione, furto di cookie | Asticella notevolmente alzata per l'acquisizione dell'account | | **Esperienza utente** | Accesso senza password | Protezione della sessione trasparente | Esperienza sicura e senza interruzioni | | **Archiviazione chiavi** | Credenziali vincolate al dispositivo o sincronizzate | Vincolate al dispositivo (HSM quando disponibile) | Autenticazione flessibile, rigido vincolo di sessione | | **Distribuzione** | Sostituisce le password | Migliora le sessioni esistenti | Miglioramenti incrementali della sicurezza | ### 2.4 Imparare dal fallimento del Token Binding 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)](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). Non dipende dalla connessione di rete sottostante, rendendolo compatibile con i bilanciatori di carico, i proxy e le infrastrutture cloud esistenti. ### 2.5 Implicazioni aziendali e opportunità di ROI 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. ## 3. Panorama delle minacce: Industrializzazione del furto di cookie 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. ### 3.1 L'ascesa degli infostealer ```mermaid graph TD A[L'utente scarica
software dannoso] -->|Esecuzione| B[L'infostealer si attiva
sul dispositivo] B --> C[Individua i dati del browser] C --> D[Archiviazione dei cookie
Chrome/Edge/Firefox] C --> E[Database delle password] C --> F[Wallet crypto] D --> G[Decrittografa utilizzando
credenziali del sistema operativo] E --> G F --> G G --> H[Crea un file di log
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
proprio browser] L --> M[Bypassa l'MFA] M --> N[Acquisizione dell'account
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](https://www.corbado.com/blog/passkey-webauthn-database-guide)) 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](https://www.corbado.com/blog/digital-wallet-assurance) di criptovalute. ### 3.2 Il mercato dei "Log" Questi log vengono aggregati e venduti sui [marketplace](https://www.corbado.com/passkeys-for-e-commerce) 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](https://www.corbado.com/blog/passkeys-amazon-cognito) 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](https://www.corbado.com/it/blog/psd2-passkey) (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](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc), apparendo al server come l'utente che ritorna su una scheda attiva. ### 3.3 La minaccia di Google Workspace e Microsoft Entra 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](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html) 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](https://www.corbado.com/blog/2sv-vs-2fa) / passkey fermano) al furto di cookie (che [2SV](https://www.corbado.com/blog/2sv-vs-2fa) / passkey spesso non fermano). ### 3.4 I limiti del "Device Fingerprinting" 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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), 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. ## 4. Architettura tecnica: Come funziona DBSC Le [Device Bound Session Credentials](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (DBSC) introducono un'[API e un protocollo standardizzati](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) 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. ### 4.1 Componenti principali | **Componente** | **Descrizione** | **Ruolo in DBSC** | | ------------------------------ | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **User agent (browser)** | L'applicazione client (Chrome, Edge, ecc.). | Gestisce la coppia di chiavi, gestisce l'interazione con l'HSM e intercetta le richieste di rete per allegare prove. | | **Relying party (server)** | L'applicazione web (es. portale bancario). | Emette sfide, verifica le firme e gestisce il ciclo di vita della sessione. | | **Archiviazione delle chiavi** | Archiviazione sicura (TPM, Secure Enclave, o altro) | Memorizza la chiave privata. Chrome usa il TPM su Windows quando disponibile; la specifica è agnostica riguardo all'implementazione. | | **Cookie di sessione** | Un cookie HTTP standard. | Utilizzato come token bearer, ma con una durata molto breve (es. 5-10 minuti). | | **Prova di possesso** | Una firma crittografica. | Un JWT inviato dal browser per dimostrare di possedere ancora la chiave privata. | ### 4.2 Il ciclo di vita del protocollo DBSC Il ciclo di vita DBSC consente una transizione fluida da una sessione standard a una sessione vincolata, garantendo la retrocompatibilità e un miglioramento progressivo. ```mermaid 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 ``` #### 4.2.1 Fase 1: Avvio e vincolo 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 \.\.\ ``` 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". #### 4.2.2 Fase 2: Il ciclo dei cookie a breve termine 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. #### 4.2.3 Fase 3: Aggiornamento (Prova del possesso) 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: \ Secure-Session-Response: \ ``` 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](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials). ### 4.3 Sfumature di implementazione #### 4.3.1 Difesa "Lift and Shift" ```mermaid graph LR subgraph "Dispositivo della vittima" A[Sessione utente
con DBSC] B[Chiave privata
HSM/TPM] C[Cookie +
ID Sessione] A --> B A --> C B -.->|Non esportabile| X[Impossibile estrarre
la chiave privata] end subgraph "Scenario di attacco" D[Il RedLine Stealer
infetta il dispositivo] D --> E[Ruba Cookie
e ID Sessione] E --> F[Esporta verso
l'attaccante] end subgraph "Dispositivo dell'attaccante" G[Importa il cookie
rubato] H[Tenta di
usare la sessione] I[Il server richiede
l'aggiornamento DBSC] J[Non può firmare
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. #### 4.3.2 Ambito e privacy La privacy è un obiettivo di progettazione centrale di DBSC. La [specifica del W3C](https://www.w3.org/TR/dbsc/) 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. #### 4.3.3 Considerazioni lato server 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. ## 5. Implicazioni aziendali e di prodotto Oltre alle specifiche tecniche, DBSC comporta implicazioni significative per la strategia aziendale, le roadmap di prodotto e gli assetti di conformità. ### 5.1 Il ROI della sicurezza senza attriti 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](https://www.corbado.com/it/blog/costo-implementazione-passkey-fte) milioni in perdite per frode. - **Costi di supporto:** Il recupero dell'account è costoso. [Prevenire l'hackeraggio in primo luogo](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/) riduce direttamente questo onere operativo. - **Ottimizzazione delle conversioni:** Nell'[e-commerce](https://www.corbado.com/passkeys-for-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. ### 5.2 Conformità e "Stato dell'arte" 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](https://www.corbado.com/passkeys-for-payment) 2 richiede l'"[Autenticazione forte del cliente](https://www.corbado.com/it/blog/psd2-passkey)" (SCA). Sebbene l'[SCA](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) si concentri sull'accesso, il [collegamento dinamico](https://www.corbado.com/it/blog/collegamento-dinamico-passkey-spc) della sessione al dispositivo si allinea perfettamente con gli obiettivi della direttiva di vincolare l'autenticazione a importi e beneficiari specifici. ### 5.3 High Assurance vs. Moderate Assurance I [whitepaper dell'Alleanza FIDO](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) sottolineano il concetto di "Livelli di affidabilità" (Assurance Levels). - **Moderate Assurance:** Utilizza [passkey sincronizzate](https://www.corbado.com/it/blog/passkey-device-bound-vs-sincronizzate) (come quelle del [Portachiavi iCloud](https://www.corbado.com/it/faq/passkey-trasferimento-nuovo-iphone)). 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](https://www.corbado.com/passkeys-for-banking) 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. ## 6. DBSC rispetto alle alternative Per apprezzare appieno DBSC, dobbiamo confrontarlo con altre tecnologie che hanno tentato di risolvere problemi simili. ```mermaid 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 ``` ### 6.1 DBSC vs Token Binding 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](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/). 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. ### 6.2 DBSC vs DPoP (Demonstrating Proof of Possession) [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) è lo standard per i token OAuth "sender-constrained". Associa sia gli [access token](https://www.corbado.com/glossary/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](https://openid.net/specs/fapi-2_0-security-profile.html) 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](https://www.corbado.com/glossary/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. | Aspetto | DPoP | DBSC | | ------------------------ | --------------------------------------------- | ------------------------------ | | **Bersaglio** | Access e refresh token OAuth | Cookie di sessione del browser | | **Archiviazione chiavi** | Contesto dell'app (best practice: API del SO) | Supportato da hardware (TPM) | | **Resistenza a XSS** | ⚠️ Dipende dall'implementazione | ✅ Chiavi non esportabili | | **Uso principale** | App native, SPA, FAPI 2.0 | Sessioni web lato utente | **Sinergia:** Come osserva l'[Alleanza FIDO](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/), 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](https://www.corbado.com/passkeys-for-banking) regolamentato), DBSC per le sessioni del browser. Insieme chiudono il vettore di attacco "lift and shift" sull'intero ciclo di vita della sessione. ### 6.3 DBSC vs cookie a breve termine (da soli) 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. ## 7. Shared Signals e Risposta Dinamica (CAEP/RISC) ```mermaid %%{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
(CrowdStrike, Defender) participant IdP as Identity Provider
(Okta, Google, Azure) participant SP1 as Service Provider 1
(Slack) participant SP2 as Service Provider 2
(Salesforce) participant SP3 as Service Provider 3
(App bancaria) participant Session as Sessione utente
(Protetta da DBSC) Note over ST,Session: Fase di rilevamento delle minacce ST->>ST: Rileva malware sul
dispositivo dell'utente ST->>IdP: Segnale RISC:
"Dispositivo compromesso" Note over IdP,SP3: Fase di propagazione del segnale IdP->>SP1: Evento CAEP:
"Dispositivo compromesso" IdP->>SP2: Evento CAEP:
"Dispositivo compromesso" IdP->>SP3: Evento CAEP:
"Dispositivo compromesso" Note over SP1,Session: Fase di applicazione (con DBSC) Session->>SP1: Prossimo tentativo di aggiornamento
(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)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/), 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](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/) 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. ## 8. Supporto dei browser e dell'ecosistema 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. ### 8.1 Google Chrome 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](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/), 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) in modo che la sessione del [relying party](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkeys-single-sign-on-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](https://support.google.com/chrome/a/answer/2657289), controllata tramite policy aziendale. Questa protegge Gmail/Workspace ed è ora la stessa famiglia di tecnologie in GA per il web in generale. ### 8.2 Microsoft Edge e Windows Microsoft sta partecipando attivamente. - **Stato:** Edge ha condotto un [Origin Trial DBSC](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d) 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)](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token) per l'[SSO](https://www.corbado.com/blog/passkeys-single-sign-on-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. ### 8.3 Apple Safari (WebKit) La posizione di Apple è critica per la copertura mobile. - **Stato:** WebKit ha una [issue sulle posizioni relative agli standard](https://github.com/WebKit/standards-positions/issues/281) 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". ### 8.4 Mozilla Firefox Mozilla ha una [issue sulle posizioni relative agli standard](https://github.com/mozilla/standards-positions/issues/912) 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. ## 9. Raccomandazioni: Proteggere gli utenti oggi 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: ### 9.1 Azioni immediate (ora che Chrome 146 è in GA) 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. ### 9.2 Pianificazione strategica (prossimi 12 mesi) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn)), 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](https://www.corbado.com/blog/auth0-passkeys-analysis) 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. ### 9.3 Best practice per l'implementazione - **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. ## 10. Come Corbado può aiutare: Un ponte verso il futuro 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. ### 10.1 Le fondamenta: le passkey 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. ### 10.2 Il futuro: DBSC per il rilevamento dei dispositivi attendibili 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](https://www.corbado.com/it/blog/passkey-device-bound-vs-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**](https://docs.corbado.com/corbado-connect/features/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](https://www.corbado.com/contact). ### 10.3 Graceful Fallback (la realtà "ibrida") Per i prossimi anni, il web sarà ibrido. Alcuni utenti avranno browser compatibili con DBSC (Chrome su [Windows 11](https://www.corbado.com/blog/passkeys-windows-11)); altri useranno sistemi più vecchi. Gestire questa frammentazione è difficile. Il motore [**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/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. ## 11. Conclusione: La strada da percorrere per DBSC 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](https://www.corbado.com/blog/device-bound-session-credentials-dbsc) (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](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) 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](https://www.corbado.com/blog/passkey-adoption-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](https://www.corbado.com/features) 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](https://www.w3.org/TR/dbsc/) è 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](https://www.corbado.com/it/blog/password-complesse-violate-presto) 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. ## Domande frequenti ### In che modo DBSC lavora con CAEP e RISC per revocare le sessioni compromesse in tempo reale? 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. ### Qual è la differenza tra DBSC e DPoP per la protezione delle sessioni delle applicazioni web? DPoP (RFC 9449) associa gli [access token](https://www.corbado.com/glossary/access-token) e refresh token OAuth a una chiave pubblica a livello di applicazione, proteggendo principalmente le chiamate API in [app native](https://www.corbado.com/it/blog/webauthn-relying-party-id-rpid-passkey) 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. ### Perché DBSC consente durate di sessione maggiori senza aumentare i rischi per la sicurezza? 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. ### Quale ROI possono aspettarsi le aziende dall'implementazione di DBSC? 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](https://www.corbado.com/passkeys-for-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.