Passkey: più sicurezza, ma a quale prezzo per la nostra libertà digitale?

Le passkey promettono di eliminare le password, proteggere dal phishing e semplificare l'accesso ai servizi online. Ma non tutte funzionano allo stesso modo. Alcune possono essere sincronizzate e trasferite, altre restano vincolate a un dispositivo, mentre certi meccanismi consentono ai siti di stabilire quali sistemi di autenticazione accettare. Vediamo come funzionano davvero, quali rischi comportano e perché sicurezza, privacy e libertà digitale non sono necessariamente la stessa cosa.

Una tecnologia più sicura è sempre una tecnologia migliore?

Immaginiamo di utilizzare un servizio online da diversi anni. Abbiamo scelto una password, l'abbiamo conservata nel nostro gestore di credenziali e magari abbiamo attivato anche l'autenticazione a due fattori.

Un giorno il servizio ci propone di abbandonare la password e utilizzare una passkey. La promessa è allettante: accessi più rapidi, niente codici da ricordare e una protezione molto più efficace contro il furto delle credenziali.

Confermiamo con l'impronta digitale e tutto funziona. Apparentemente abbiamo soltanto sostituito una procedura complicata con una più semplice.

Ma dove si trova adesso la nostra credenziale? Possiamo farne una copia di sicurezza? Potremo utilizzarla su Linux, su un telefono con un sistema operativo alternativo oppure con un programma sviluppato da noi? E se decidessimo di abbandonare Google, Apple o il gestore di password che stiamo utilizzando, potremmo portarla con noi?

Sono domande meno immediate della comodità di un accesso con l'impronta digitale, ma riguardano un principio fondamentale: essere proprietari di un account non significa necessariamente avere il pieno controllo degli strumenti con cui possiamo accedervi.

Il dibattito è stato rilanciato nell'ottobre 2026 dall'articolo Passkeys are a trap. Do not use them, pubblicato su Non-Functional.

La preoccupazione espressa dall'autore merita attenzione. Tuttavia, per capire se le passkey costituiscano davvero una minaccia alla nostra libertà, dobbiamo distinguere le loro caratteristiche tecniche dalle politiche commerciali dei servizi e dai possibili utilizzi futuri.

Che cos'è una passkey e come funziona?

Una passkey è una credenziale digitale basata sulla crittografia a chiave pubblica. A differenza di una password, non consiste in una sequenza di caratteri che dobbiamo ricordare e comunicare al sito.

Il sistema utilizza una coppia di chiavi matematicamente collegate, con funzioni differenti.

La chiave privata viene custodita dal dispositivo o dal gestore di passkey. È il segreto che deve essere protetto e che permette di dimostrare il possesso della credenziale.

La chiave pubblica, invece, viene registrata dal servizio online. Può essere utilizzata per verificare una firma prodotta con la chiave privata, ma non consente, in condizioni crittografiche normali, di ricostruire quest'ultima.

Quando accediamo a un sito, il procedimento è il seguente.

1. Il sito invia al nostro dispositivo una richiesta contenente una sfida crittografica, chiamata challenge.
2. Il dispositivo ci chiede di autorizzare l'operazione, eventualmente verificando il PIN, l'impronta digitale o il volto.
3. L'autenticatore utilizza la chiave privata per firmare i dati necessari alla verifica, compresa la sfida.
4. Il sito controlla la firma con la chiave pubblica precedentemente registrata e, se le verifiche sono corrette, autorizza l'accesso.

La chiave privata non viene inviata al sito durante questa procedura.

Inoltre, ogni credenziale è associata a uno specifico servizio. Una passkey creata per un dominio non può essere normalmente utilizzata per autenticarsi su un dominio diverso.

È questa proprietà, chiamata verifier name binding, a rendere WebAuthn particolarmente resistente al phishing.

Se qualcuno realizza una falsa pagina di accesso che assomiglia a quella della nostra banca, il browser non dovrebbe permettere di utilizzare su quel dominio fraudolento la passkey registrata per quello autentico.

Non significa che tutti gli attacchi informatici diventino impossibili. Un dispositivo compromesso, una sessione già rubata o una procedura di recupero dell'account poco sicura possono ancora offrire opportunità a un attaccante.

Significa, però, che il classico furto della password attraverso una falsa pagina di login diventa molto più difficile.

Ma allora perché serve l'impronta digitale?

Una delle incomprensioni più frequenti riguarda il ruolo dei dati biometrici.

Quando utilizziamo il riconoscimento facciale o l'impronta digitale per accedere con una passkey, normalmente non stiamo inviando al sito una copia del nostro volto o della nostra impronta.

La verifica biometrica avviene localmente, attraverso il dispositivo e il relativo sistema di autenticazione. Il sito riceve una risposta crittografica e, quando previsto, un'indicazione che la verifica locale dell'utente è stata eseguita.

Non è nemmeno obbligatorio utilizzare la biometria. Molti sistemi permettono di autorizzare la passkey attraverso il PIN o altri meccanismi di sblocco.

Naturalmente, questo non elimina le questioni di privacy legate alla raccolta e alla conservazione dei dati biometrici da parte del dispositivo. Semplicemente, tali questioni sono distinte dal funzionamento del protocollo WebAuthn.

Password, TOTP e passkey: cosa cambia davvero?

Prima di esaminare le diverse passkey, conviene confrontarle con le alternative più diffuse.

Le password hanno un vantaggio evidente: sono semplici da capire, possono essere conservate in molti modi e generalmente funzionano su qualsiasi dispositivo dotato di un browser.

Il loro principale problema è che sono segreti condivisi. Per autenticarsi, il sito deve poter verificare una conoscenza che anche l'utente possiede. Se quella conoscenza viene rubata, intercettata attraverso phishing o riutilizzata impropriamente, la sicurezza dell'account può essere compromessa.

L'autenticazione TOTP, invece, utilizza codici temporanei generati a partire da una chiave segreta condivisa e dall'orario corrente. È il meccanismo utilizzato da numerose applicazioni di autenticazione.

Il sistema è standardizzato nella RFC 6238 e non richiede necessariamente uno smartphone, una connessione Internet o il servizio di una grande azienda.

Un'applicazione compatibile può generare gli stessi codici se dispone del segreto iniziale e di un orologio sufficientemente preciso.

Ma TOTP presenta un limite importante: un codice temporaneo può essere intercettato da una falsa pagina di accesso e utilizzato immediatamente da un attaccante. La sua breve durata riduce la finestra di utilizzo, non elimina il phishing.

Questo confronto mostra già un aspetto importante: non esiste un unico sistema migliore in tutte le circostanze.

Le caratteristiche che rendono una credenziale difficile da copiare per un criminale possono anche renderla difficile da recuperare per il legittimo proprietario.

Perciò, quando parliamo di sicurezza, dobbiamo sempre chiederci da quale minaccia vogliamo proteggerci e quali possibilità siamo disposti a sacrificare.

Non tutte le passkey sono uguali

La parola passkey è un termine comune per credenziali basate sugli standard FIDO e WebAuthn, ma il modo in cui queste credenziali vengono create, conservate e utilizzate può cambiare notevolmente.

La distinzione fondamentale riguarda le passkey sincronizzate e quelle legate a un singolo dispositivo.

Accanto a questa differenza troviamo altre caratteristiche, come la protezione hardware, la possibilità di esportazione, la verifica locale dell'utente e l'attestazione dell'autenticatore.

Queste proprietà non identificano sempre categorie reciprocamente esclusive. Una passkey può, ad esempio, essere sincronizzata, conservata attraverso un gestore software e richiedere contemporaneamente la verifica dell'utente.

1. Passkey sincronizzate: la comodità del cloud

Le passkey sincronizzate, chiamate synced passkeys, sono progettate per essere disponibili su più dispositivi attraverso un gestore di credenziali.

Immaginiamo di creare una passkey sul nostro telefono e di ritrovarla, senza doverla registrare nuovamente sul sito, anche su un altro dispositivo collegato allo stesso gestore.

La sincronizzazione permette questo comportamento trasferendo in modo protetto il materiale crittografico necessario all'autenticazione.

Fornitori come Apple, Google e diversi gestori indipendenti utilizzano sistemi di protezione e sincronizzazione delle credenziali. Le implementazioni possono essere differenti e non tutte offrono identiche modalità di recupero, esportazione e trasferimento.

Secondo le specifiche FIDO, la sincronizzazione deve proteggere adeguatamente le chiavi; le principali architetture prevedono la cifratura end-to-end, ma la sicurezza complessiva dipende anche da come vengono gestiti dispositivi autorizzati, recupero dell'account e chiavi di cifratura.

Il rischio principale non è che il cloud sia necessariamente insicuro. È che la possibilità di accedere alle nostre credenziali, aggiungere nuovi dispositivi o recuperare un account possa dipendere dalle decisioni di un intermediario.

Se il nostro account presso il gestore delle passkey viene sospeso, perdiamo i dispositivi autorizzati o non superiamo la procedura di recupero, potremmo non riuscire più a utilizzare credenziali perfettamente valide presso altri servizi.

Avere una copia sincronizzata non equivale quindi ad avere un sistema di recupero indipendente.

2. Passkey vincolate al dispositivo: maggiore isolamento, meno flessibilità

Le device-bound passkeys sono credenziali legate a uno specifico autenticatore.

Quando la chiave privata viene generata e custodita in un ambiente hardware che ne impedisce l'esportazione, non può essere normalmente copiata su un altro dispositivo.

Un esempio è una credenziale protetta da un modulo hardware dedicato, come un TPM, utilizzato da un sistema di autenticazione locale.

Questo modello riduce il rischio che un malware possa semplicemente leggere un file contenente la chiave privata e copiarlo su un altro computer.

Il vantaggio è significativo, ma comporta una conseguenza inevitabile: se il dispositivo viene distrutto e quella era l'unica credenziale disponibile per l'account, non possiamo recuperarla copiandola da un backup convenzionale.

La soluzione più prudente è registrare più passkey indipendenti sullo stesso account, quando il servizio lo consente.

Una credenziale può rimanere sul computer principale, mentre una seconda viene custodita su un altro dispositivo o su una chiave di sicurezza fisica.

In questo modo la perdita di un autenticatore non equivale automaticamente alla perdita dell'identità digitale.

3. Passkey su chiavi di sicurezza fisiche

Una terza possibilità consiste nell'utilizzare una chiave di sicurezza dedicata, come una chiave FIDO2 compatibile collegabile tramite USB oppure utilizzabile con NFC.

Questi dispositivi contengono componenti crittografici e sono progettati per eseguire le operazioni necessarie all'autenticazione senza esportare la chiave privata.

Il vantaggio è che l'autenticatore diventa un oggetto separato dal computer e dal telefono.

Possiamo cambiare browser, installare un altro sistema operativo o utilizzare un computer differente senza necessariamente dover trasferire la credenziale: basta portare con noi la chiave hardware e utilizzare un ambiente compatibile.

È importante distinguere due usi dello stesso dispositivo. Una chiave FIDO2 può funzionare come secondo fattore accanto a una password oppure custodire una credenziale individuabile che permette un accesso senza password.

Per chi attribuisce grande importanza all'indipendenza dai fornitori cloud, questa è una delle soluzioni più interessanti.

Non significa che una chiave hardware garantisca automaticamente anonimato o libertà assoluta. Il servizio può comunque imporre restrizioni sui dispositivi accettati e utilizzare altri sistemi per verificare identità, provenienza della connessione o integrità dell'ambiente.

Tuttavia, il fatto che la credenziale risieda in un oggetto separato limita almeno alcune forme di dipendenza dal sistema operativo.

4. Passkey gestite da software indipendente

Le passkey possono essere custodite e gestite anche da applicazioni indipendenti, comprese soluzioni open source.

Un gestore di credenziali può generare una coppia di chiavi, conservare in forma cifrata quella privata e utilizzarla per rispondere alle richieste di autenticazione WebAuthn.

A seconda del prodotto, le passkey possono rimanere locali, essere incluse in backup cifrati o venire sincronizzate attraverso un servizio.

Questa possibilità è particolarmente importante per chi desidera scegliere autonomamente il proprio software.

Un gestore multipiattaforma può anche ridurre la dipendenza da un singolo produttore di telefoni o sistemi operativi.

La possibilità di esportare una passkey introduce un compromesso importante.

Una chiave che possiamo copiare e conservare autonomamente è più semplice da recuperare, migrare e utilizzare secondo le nostre necessità. Ma può anche essere sottratta da un attaccante che riesca ad accedere al suo contenuto in chiaro.

Questo non rende sbagliata l'esportazione. Significa che la libertà di gestione richiede responsabilità nella protezione dei segreti.

Copiabili, esportabili, trasferibili: tre concetti da non confondere

Uno degli aspetti più interessanti del dibattito riguarda la possibilità di copiare o trasferire una credenziale.

Le parole sembrano simili, ma descrivono operazioni diverse.

Copiare significa produrre un'altra istanza del materiale necessario per utilizzare la stessa credenziale.

Esportare significa rendere quel materiale disponibile all'esterno del sistema che lo custodisce, eventualmente in forma cifrata e mediante un protocollo sicuro.

Trasferire significa spostare una credenziale o renderla disponibile a un nuovo gestore. Un trasferimento può avvenire copiando il segreto, ma può anche essere realizzato registrando una nuova credenziale e disattivando quella precedente.

Questa distinzione è fondamentale. Una chiave privata realmente non esportabile non può essere copiata su un altro dispositivo senza contraddire la proprietà che dovrebbe garantirne l'isolamento.

È invece possibile spostare fisicamente l'autenticatore che la contiene oppure sostituire la credenziale attraverso una nuova registrazione.

Il ruolo degli standard di portabilità

Per molti anni, trasferire le passkey tra gestori differenti è stato notevolmente più difficile rispetto all'esportazione delle password.

La FIDO Alliance ha lavorato agli standard Credential Exchange Format (CXF) e Credential Exchange Protocol (CXP), pensati per trasferire in modo protetto password, passkey e altre credenziali tra applicazioni compatibili.

Nel 2025 e nel 2026 sono arrivate implementazioni concrete. Bitwarden, per esempio, ha documentato il supporto allo scambio di credenziali su iOS e Android, con ulteriori sviluppi annunciati nel luglio 2026.

È un progresso rilevante. Non possiamo più sostenere che tutte le passkey siano necessariamente imprigionate per sempre nel gestore che le ha create.

Dobbiamo però evitare anche l'affermazione opposta: la presenza di uno standard non garantisce che qualsiasi passkey sia trasferibile fra qualsiasi coppia di applicazioni.

Le credenziali legate a hardware non esportabile rimangono un caso distinto. Inoltre, la migrazione dipende dalle funzionalità effettivamente implementate dai fornitori.

Perciò, prima di affidare decine di account a un gestore, conviene verificare le sue possibilità reali di esportazione e recupero.

Passkey protette da hardware e passkey protette da software

Un'altra distinzione riguarda il luogo in cui la chiave privata viene utilizzata e conservata.

Con una soluzione protetta da hardware, il materiale crittografico può essere custodito in un componente progettato per impedirne l'accesso diretto dal sistema operativo.

I TPM dei computer, gli elementi sicuri e altri ambienti di esecuzione isolati sono esempi di tecnologie utilizzabili a questo scopo.

Con una soluzione software, invece, la chiave privata viene protetta tramite cifratura, controlli di accesso e meccanismi applicativi.

Le due architetture possono anche coesistere: un gestore software potrebbe utilizzare componenti hardware per proteggere alcune proprie chiavi di cifratura pur consentendo la sincronizzazione delle passkey.

Occorre evitare di attribuire proprietà magiche ai componenti hardware.

Non tutti i chip sono progettati allo stesso modo, non tutti sono invulnerabili a tecniche di estrazione e non tutti dispongono di sistemi fisici di autodistruzione.

Inoltre, impedire l'estrazione di una chiave non equivale a impedire che un malware utilizzi impropriamente un autenticatore già accessibile da un dispositivo compromesso.

È una differenza essenziale per valutare la sicurezza reale.

Passkey individuabili e credenziali non individuabili

WebAuthn distingue anche tra credenziali discoverable e non-discoverable.

Le credenziali individuabili conservano nell'autenticatore le informazioni necessarie a selezionare l'account appropriato per un servizio. Consentono quindi esperienze di accesso in cui il browser propone direttamente l'identità da utilizzare.

Le credenziali non individuabili, invece, richiedono che il servizio fornisca preventivamente un identificatore di credenziale. Spesso questo avviene dopo che l'utente ha inserito il proprio nome account.

Questa seconda modalità è storicamente importante nell'ecosistema FIDO2, ma nella terminologia moderna le passkey sono credenziali individuabili. Non è quindi corretto considerare ogni vecchia credenziale WebAuthn non individuabile come una passkey equivalente.

La scelta influisce soprattutto sul funzionamento del login e sulla gestione delle credenziali. Non determina da sola il livello complessivo di privacy o libertà dell'utente.

User Presence e User Verification: essere presenti non significa essere verificati

Quando utilizziamo una passkey, il sistema può eseguire controlli differenti.

Il primo si chiama User Presence, abbreviato UP. Serve a indicare che l'autenticatore ha verificato la presenza di un utente attraverso un'azione appropriata.

Può trattarsi, per esempio, della pressione di un pulsante su una chiave hardware.

Il secondo è User Verification, o UV. Serve a indicare che l'autenticatore ha eseguito una verifica locale dell'utente, tipicamente mediante PIN, biometria o un altro meccanismo supportato.

La differenza è sottile ma importante: premere un pulsante dimostra un'interazione fisica, non necessariamente che la persona sia quella autorizzata.

UP e UV sono risultati di controlli associati alle operazioni WebAuthn, non categorie commerciali di passkey che l'utente può sempre scegliere liberamente.

Il servizio online può richiedere la verifica dell'utente e deve poi controllare correttamente il risultato ricevuto.

Questa possibilità è generalmente positiva: per accedere a un conto bancario è ragionevole chiedere una verifica più forte rispetto a quella necessaria per consultare un servizio poco sensibile.

Ma introduce una considerazione più generale: una parte delle condizioni di accesso viene stabilita dal servizio e dal suo modello di sicurezza, non esclusivamente dall'utente.

Attestation: quando il sito vuole sapere quale autenticatore utilizziamo

Arriviamo al punto più delicato dell'intera discussione.

L'attestation, o attestazione, è un meccanismo che può permettere a un servizio di ottenere informazioni crittograficamente verificabili sull'autenticatore che ha generato una credenziale.

Per capire la differenza, immaginiamo di creare una passkey con un programma sviluppato autonomamente.

Senza un'attestazione affidabile, il servizio può verificare che possediamo la chiave privata corrispondente a quella pubblica registrata, ma potrebbe non conoscere con certezza il produttore o le caratteristiche di sicurezza del nostro autenticatore.

Attraverso l'attestazione, invece, può ricevere informazioni verificabili sulla provenienza della credenziale e sull'autenticatore utilizzato, a seconda del formato supportato e delle regole applicate dal browser.

Questa capacità può essere utile, soprattutto in ambienti aziendali dove determinate operazioni richiedono dispositivi conformi a requisiti di sicurezza specifici.

Ma la stessa capacità può essere impiegata per escludere alcuni strumenti, anche quando tecnicamente compatibili con il protocollo di autenticazione.

Le principali modalità di attestazione

Le modalità tecniche hanno ulteriori distinzioni e formati, ma questi sono i principali casi utili per comprenderne le conseguenze.

È importante aggiungere che l'attestazione non equivale automaticamente alla sorveglianza del computer.

Una normale attestazione WebAuthn riguarda principalmente l'autenticatore e la provenienza della credenziale. Non certifica, per definizione, l'intero elenco dei programmi installati, l'assenza di determinate estensioni del browser o la conformità di tutto il sistema operativo.

Esistono altre forme di attestazione dell'integrità del dispositivo, e alcune architetture possono comunicare informazioni più ampie sull'ambiente. Un servizio potrebbe anche combinare diverse tecnologie per applicare restrizioni più severe.

Ma occorre distinguere ciò che WebAuthn prevede direttamente da ciò che diventerebbe possibile attraverso ulteriori sistemi di verifica.

Questa distinzione non rende irrilevante il problema della libertà digitale. Serve, piuttosto, a identificarlo correttamente.

Perché l'attestazione può diventare controversa

Immaginiamo un servizio che accetti soltanto chiavi hardware appartenenti a modelli approvati.

Una banca potrebbe adottare tale regola per proteggere operazioni particolarmente sensibili. In questo caso, l'attestazione risponderebbe a una precisa esigenza di sicurezza.

Ora immaginiamo che un servizio generalista imponga la stessa limitazione, escludendo arbitrariamente gli autenticatori open source o i dispositivi di produttori concorrenti.

Il meccanismo crittografico sarebbe lo stesso, ma l'obiettivo e le conseguenze sarebbero differenti.

Un protocollo aperto non garantisce automaticamente un mercato aperto. Se un servizio decide di accettare soltanto determinate implementazioni, può limitare concretamente le possibilità di scelta dell'utente.

Per questo è fondamentale distinguere la capacità tecnica di verificare un autenticatore dalla legittimità delle condizioni che vengono imposte sulla base di quella verifica.

L'Electronic Frontier Foundation ha analizzato queste questioni, osservando che le passkey sono generalmente ben progettate sotto il profilo della privacy, pur potendo rivelare alcune informazioni aggiuntive rispetto a una semplice password.

Tra queste possono figurare informazioni sul modello dell'autenticatore, sul gestore utilizzato e, in determinate implementazioni, metadati potenzialmente utili alla correlazione tra account.

Le garanzie offerte dai browser e dai sistemi di anonimizzazione diventano quindi particolarmente importanti.

Un sito può sapere quale sistema operativo utilizziamo?

Nella pratica, molti siti possono già ottenere informazioni sul browser, sul sistema operativo e su altre caratteristiche del dispositivo attraverso meccanismi indipendenti dalle passkey.

Queste informazioni non sono necessariamente attendibili e non equivalgono a una prova crittografica dell'integrità del sistema.

L'attestazione WebAuthn può aggiungere informazioni verificabili sull'autenticatore, ma non trasforma automaticamente tutti i dettagli del computer in dati certificati.

Per arrivare a impedire l'accesso a chi utilizza un sistema operativo modificato, il sito dovrebbe disporre di meccanismi che gli permettano di verificare le proprietà che intende imporre oppure rifiutare una categoria di autenticatori associata a determinati ambienti.

Esistono tecnologie e servizi di verifica dell'integrità del dispositivo che possono essere utilizzati a questo scopo, ma non vanno confusi con l'autenticazione tramite passkey.

Resta però un problema di fondo: se un numero crescente di servizi essenziali richiedesse dispositivi o sistemi approvati da pochi soggetti, la libertà di scegliere il proprio software potrebbe risultarne limitata.

Questo scenario è tecnicamente plausibile in alcuni contesti, ma non è una conseguenza inevitabile dell'adozione delle passkey.

Dipende dalle decisioni dei servizi, dalle possibilità offerte dalle piattaforme e dalle regole che governano l'accesso digitale.

Privacy: cosa può sapere un sito e cosa può sapere il nostro gestore?

Quando discutiamo della privacy delle passkey, dobbiamo considerare almeno tre soggetti: l'utente, il servizio online e il gestore delle credenziali.

Dal punto di vista del servizio, una passkey è generalmente associata a uno specifico account e non rappresenta un identificatore universale condiviso fra tutti i siti.

Questo è un vantaggio importante: due siti distinti non ricevono automaticamente una stessa credenziale che permetta loro di riconoscere una persona.

La privacy, però, non dipende soltanto dalla chiave crittografica.

Il servizio può conoscere il nostro indirizzo IP, utilizzare cookie, registrare informazioni sul dispositivo o identificarci tramite il profilo personale.

Il gestore delle passkey, a sua volta, può trattare informazioni sugli account e sulla sincronizzazione, secondo la propria architettura.

Anche quando le chiavi private sono protette con cifratura end-to-end, non tutti i metadati sono necessariamente nascosti al fornitore.

La distinzione più importante è che sicurezza crittografica e riservatezza dei dati personali sono proprietà differenti.

Un sistema può proteggere perfettamente una chiave privata e, contemporaneamente, raccogliere molte informazioni sull'utente attraverso altri canali.

Viceversa, un sistema che rivela poche informazioni potrebbe offrire una protezione inadeguata contro il furto dell'account.

Possiamo continuare a condividere i nostri account?

Le password hanno una caratteristica particolare: conoscendo lo stesso segreto, due persone possono generalmente utilizzarlo per accedere allo stesso account.

Le passkey possono rendere questo comportamento meno immediato.

Con una chiave hardware non esportabile, per esempio, condividere la credenziale richiede normalmente di condividere fisicamente l'autenticatore.

Con le passkey sincronizzate, la possibilità di condivisione dipende dalle funzioni offerte dal gestore e dalle politiche applicate.

Esiste però un'altra soluzione: un servizio può consentire di registrare più passkey distinte sullo stesso account.

Due persone potrebbero così utilizzare credenziali differenti, senza scambiarsi la stessa chiave privata.

Il servizio sarebbe potenzialmente in grado di distinguere quale credenziale è stata utilizzata, ma la condivisione non sarebbe necessariamente impedita.

Questo chiarisce perché non possiamo affermare che le passkey vietino tecnicamente la condivisione degli account.

Possono modificare il modo in cui avviene e offrire ai servizi strumenti per applicare politiche di accesso differenti.

La decisione di consentire o vietare la condivisione rimane, in buona parte, una scelta del fornitore del servizio.

Il vero rischio: perdere il controllo delle credenziali

Consideriamo ora una situazione più concreta.

Utilizziamo un gestore sincronizzato per conservare tutte le passkey. Grazie alla cifratura end-to-end, un attaccante che comprometta i server del fornitore non dovrebbe poterle utilizzare semplicemente leggendo i dati archiviati.

Ma che cosa succede se perdiamo tutti i nostri dispositivi?

Dobbiamo affidarci al processo di recupero predisposto dal gestore.

Se questo processo è troppo permissivo, può diventare un punto vulnerabile. Se è troppo restrittivo, rischiamo di rimanere esclusi dai nostri stessi account.

L'autenticazione forte non elimina dunque il problema del recupero: lo sposta su altri elementi dell'architettura.

Questo vale anche per le procedure di emergenza dei singoli siti.

Se un sito consente di aggirare una passkey attraverso una semplice email di recupero, la sicurezza effettiva dell'account dipenderà anche dalla protezione della casella email.

Se invece non esiste alcun meccanismo alternativo, la perdita dell'unico autenticatore può diventare definitiva.

Un esempio reale: gli attacchi alle passkey sincronizzate nel 2026

Nell'agosto 2026, i ricercatori di Palo Alto Networks Unit 42 hanno pubblicato uno studio su tre tecniche di attacco contro l'implementazione delle passkey sincronizzate di Google Password Manager in Chrome su Windows.

La ricerca ha mostrato come un malware già presente nel computer della vittima potesse sfruttare debolezze nelle procedure di fiducia del dispositivo, verifica dell'utente e gestione del materiale crittografico.

Le tecniche, riunite sotto il nome Pass-ta-key, comprendevano scenari di utilizzo non autorizzato delle credenziali e di estrazione delle chiavi in circostanze specifiche.

È necessario precisare che lo studio riguardava una determinata implementazione e presupponeva la precedente compromissione del computer. Non dimostrava una vulnerabilità generale della matematica utilizzata da WebAuthn.

Il caso è comunque istruttivo.

La sicurezza di una passkey non dipende esclusivamente dall'algoritmo crittografico. Dipende anche dal software, dall'autenticatore, dai processi di sincronizzazione, dai controlli del servizio e dalle condizioni in cui viene utilizzata.

Un sistema di autenticazione deve essere valutato nella sua interezza, non soltanto attraverso la robustezza della chiave privata.

La libertà digitale non consiste soltanto nel possedere i propri dati

La questione più ampia riguarda il rapporto tra gli utenti e le infrastrutture che rendono possibile la vita online.

Per molti anni siamo stati abituati a considerare la password come qualcosa di nostro, almeno nel senso pratico del termine.

Possiamo ricordarla, scriverla, custodirla in un file cifrato o affidarla a un gestore. Possiamo anche decidere di sostituire completamente lo strumento con cui la conserviamo.

Le passkey cambiano questo rapporto, ma non necessariamente in un'unica direzione.

Da un lato, un gestore indipendente e interoperabile può offrirci una soluzione più sicura delle password tradizionali senza compromettere in modo significativo la nostra autonomia.

Dall'altro, un ecosistema che richiede dispositivi certificati, sincronizzazione obbligatoria e procedure di recupero controllate da un singolo fornitore può aumentare la dipendenza da quell'infrastruttura.

Il punto non è rifiutare qualsiasi sistema centralizzato. È evitare che una scelta di comodità diventi gradualmente una condizione obbligatoria per accedere a servizi indispensabili.

Questo riguarda anche il diritto di continuare a utilizzare dispositivi funzionanti, sistemi operativi alternativi, software libero e tecnologie che non dipendono dall'approvazione commerciale di pochi produttori.

Il rischio di esclusione digitale aumenta quando i requisiti di accesso vengono definiti in modo opaco o senza ragionevoli alternative.

Quali caratteristiche dovrebbe avere un sistema rispettoso dell'utente?

Un ecosistema di autenticazione realmente aperto dovrebbe rendere comprensibili le proprietà delle credenziali utilizzate, consentire di scegliere il proprio gestore e offrire procedure di migrazione documentate.

I servizi dovrebbero accettare differenti autenticatori conformi agli standard, salvo esigenze di sicurezza specifiche e motivate. Quando richiedono attestazioni più restrittive, dovrebbero spiegare quali garanzie cercano di ottenere e quali dispositivi escludono.

Sarebbe inoltre importante permettere agli utenti di registrare più credenziali indipendenti, consultare l'elenco degli autenticatori autorizzati e revocare quelli non più utilizzati.

Le informazioni sull'attestazione dovrebbero essere limitate a ciò che serve davvero per valutare la sicurezza, evitando identificatori persistenti non necessari.

Infine, la scelta di utilizzare un sistema operativo libero o un gestore open source non dovrebbe rappresentare, da sola, una ragione sufficiente per essere esclusi da servizi ordinari.

Quale soluzione scegliere oggi?

Non esiste una risposta uguale per tutti.

Chi teme soprattutto il phishing e vuole utilizzare facilmente gli stessi account su telefono e computer può trovare nelle passkey sincronizzate un miglioramento significativo.

Chi desidera ridurre la dipendenza dai grandi ecosistemi può scegliere un gestore multipiattaforma che offra esportazione, backup sicuri e procedure di recupero verificabili.

Chi gestisce account particolarmente sensibili può preferire credenziali vincolate a chiavi hardware, registrando più autenticatori indipendenti.

Una strategia particolarmente equilibrata consiste nell'utilizzare passkey dove offrono vantaggi evidenti, senza rinunciare a un secondo metodo di accesso indipendente quando disponibile e sufficientemente sicuro.

Per gli account più importanti, come email principale, gestore delle credenziali e servizi finanziari, è prudente controllare periodicamente i metodi di recupero, le passkey registrate e i dispositivi ancora autorizzati.

Un backup non verificato non è una garanzia di recupero.

Le passkey dovrebbero essere obbligatorie?

È ragionevole che un'organizzazione richieda livelli di autenticazione elevati per proteggere informazioni particolarmente sensibili.

Una banca, un ospedale o un'infrastruttura critica possono avere requisiti diversi rispetto a un forum dedicato a un hobby.

Il problema nasce quando requisiti molto restrittivi vengono applicati indiscriminatamente, senza considerare il rischio effettivo e senza offrire alternative adeguate.

Un servizio che richiede una chiave hardware non esportabile per autorizzare un'operazione finanziaria di grande valore può avere una motivazione tecnica convincente.

Un sito che obbliga tutti gli utenti ad acquistare uno specifico modello di telefono per poter leggere contenuti ordinari si colloca in una situazione decisamente diversa.

L'autenticazione dovrebbe essere proporzionata alla sensibilità dell'operazione e non diventare uno strumento per imporre preferenze commerciali non necessarie.

Per questa ragione è importante che gli standard rimangano aperti, che esistano implementazioni indipendenti e che l'interoperabilità non dipenda soltanto dalla buona volontà di pochi produttori.

Conclusione: più sicurezza, senza rinunciare alla libertà

Le passkey rappresentano un progresso importante nell'autenticazione digitale.

Eliminano molti problemi delle password tradizionali, riducono fortemente il rischio di phishing e permettono di realizzare procedure di accesso più semplici.

Sarebbe sbagliato ignorare questi vantaggi.

Sarebbe altrettanto sbagliato pensare che una credenziale crittograficamente sicura garantisca automaticamente privacy, indipendenza e controllo.

Sono caratteristiche diverse, che richiedono scelte progettuali differenti.

Una credenziale può essere molto difficile da rubare e contemporaneamente impossibile da trasferire. Un gestore può proteggere le chiavi con ottima crittografia, ma vincolare il recupero al proprio ecosistema. Un servizio può utilizzare correttamente l'attestazione dell'autenticatore e, nello stesso tempo, adottare politiche eccessivamente restrittive.

Nessuna di queste conseguenze è inevitabile. Ed è proprio questo il punto.

La domanda non dovrebbe essere soltanto quanto sia difficile per un criminale utilizzare le nostre credenziali, ma anche quanto sia semplice per noi continuare a utilizzarle, conservarle e trasferirle senza dipendere da autorizzazioni arbitrarie.

Le passkey non devono necessariamente diventare una trappola. Possono far parte di un Internet più sicuro e rispettoso degli utenti, purché portabilità, trasparenza, interoperabilità e libertà di scelta vengano considerate requisiti fondamentali e non semplici funzionalità accessorie.

Perché una tecnologia che protegge i nostri account dovrebbe proteggere anche la nostra possibilità di scegliere come accedervi.

---

Fonti e approfondimenti

L'articolo è stato elaborato confrontando analisi critiche, documentazione tecnica e indicazioni indipendenti. Le fonti principali sono:

1. Non-Functional — Passkeys are a trap. Do not use them — Il contributo critico da cui nasce la discussione.
2. FIDO Alliance — Passkeys — Definizioni, architettura e principali caratteristiche delle passkey.
3. W3C — Web Authentication Level 3 — Specifica normativa per credenziali, verifica dell'utente, attestazione e privacy.
4. Mozilla Developer Network — Web Authentication API — Spiegazione tecnica delle credenziali individuabili e non individuabili.
5. Electronic Frontier Foundation — Passkeys and Privacy — Analisi indipendente delle implicazioni sulla privacy.
6. Electronic Frontier Foundation — What the !#@% is a Passkey? — Introduzione divulgativa a sicurezza, backup e passkey.
7. NIST SP 800-63B — Syncable Authenticators — Requisiti e rischi delle credenziali sincronizzabili.
8. FIDO Alliance — Credential Exchange Specifications — Specifiche per lo scambio delle credenziali tra gestori.
9. Bitwarden — Portable Passkeys — Sviluppi pratici nella portabilità, aggiornati al luglio 2026.
10. Palo Alto Networks Unit 42 — Pass the Passkey — Ricerca pubblicata nell'agosto 2026 sui rischi di una specifica implementazione delle passkey sincronizzate.

Analisi aggiornata a ottobre 2026. Compatibilità, procedure di esportazione e politiche di attestazione possono cambiare con l'evoluzione dei sistemi operativi e dei gestori di credenziali.