Passkey, sono davvero una trappola? Tra verità e falsi miti

Avete sostituito la password con una passkey: quando dovete accedere a un sito, Windows Hello vi chiede il PIN, lo smartphone riconosce il volto oppure appoggiate il dito sul sensore. L’operazione richiede pochi secondi e, soprattutto, non state digitando una password che un sito phishing potrebbe sottrarvi.

Fin qui tutto semplice. Ma cosa succederebbe se, un giorno, un servizio rispondesse che la passkey funziona, ma quella generata dal dispositivo in uso non è accettabile?

Su IlSoftware.it abbiamo visto perché il piano per sostituire le password con le passkey sta procedendo più lentamente del previsto, nonostante i vantaggi in termini di sicurezza; abbiamo raccontato dove le passkey sono già diventate la prima scelta rispetto alle password e analizzato quali rischi le passkey non riescono comunque a eliminare.

Quando creiamo una passkey da usare al posto della password, il dispositivo crea invece una coppia di chiavi crittografiche: una privata, che resta sotto il controllo dell’utente e dell’autenticatore, e una pubblica che può essere consegnata al servizio.

Al momento dell’accesso al servizio, il sito invia una richiesta che il nostro dispositivo firma utilizzando la chiave privata. Il server controlla la firma con la chiave pubblica già registrata e può così verificare che possediamo ancora la credenziale corretta, senza che la chiave privata debba mai essere trasmessa.

WebAuthn: il meccanismo alla base delle passkey

Alla base del funzionamento delle passkey c’è WebAuthn (Web Authentication API), lo standard Web – sviluppato nell’ambito degli standard FIDO – che permette a browser, siti e autenticatori di dialogare per creare e utilizzare credenziali a chiave pubblica.

È proprio WebAuthn a prevedere un meccanismo poco visibile nell’uso quotidiano: il sito può, in determinate circostanze, chiedere non soltanto se la firma sia corretta ma anche quale tipo di tipo di autenticatore ha generato la credenziale e se sia possibile fidarsi. Questo genere di procedura si chiama attestation.

La firma crittografica potrebbe quindi essere perfettamente valida e l’autenticatore conforme a WebAuthn, ma il sito potrebbe comunque decidere di non fidarsi abbastanza della tecnologia che ha creato la credenziale. Non è lo scenario normale con cui oggi usiamo le passkey, ma tecnicamente è possibile ed è uno degli aspetti meno conosciuti dello standard.

Le passkey sono una trappola: la provocazione che ha acceso il dibattito

In questi giorni sta diventando virale il pezzo dal titolo volutamente provocatorio “Passkeys are a trap. Do not use them“. Tradotto: le password sono una trappola, non utilizzatele!

L’autore non sostiene che le passkey siano crittograficamente deboli; al contrario, riconosce i loro vantaggi rispetto alle password, soprattutto per quanto riguarda il phishing. La critica riguarda il potere che il servizio può esercitare nella scelta degli autenticatori considerati affidabili.

Secondo la tesi esposta nell’articolo, attraverso il meccanismo di attestation descritto in precedenza, un sito potrebbe distinguere tra credenziali prodotte da sistemi approvati e altre generate da hardware o software che non considera sufficientemente affidabili. Portando questo principio alle estreme conseguenze, l’autore teme uno scenario nel quale piattaforme, sistemi operativi alternativi o implementazioni indipendenti possano essere progressivamente esclusi.

WebAuthn consente effettivamente a una relying party, cioè al servizio che utilizza l’autenticazione, di applicare proprie policy sugli autenticatori. È invece troppo ampio concludere che una normale attestation WebAuthn consenta automaticamente a un sito di controllare sistema operativo, firmware, ROM installata e configurazione complessiva del dispositivo.

Cosa succede quando creiamo una passkey

Quando premiamo il pulsante Crea passkey, il sito fornisce al browser una serie di istruzioni tramite WebAuthn. Il browser individua quindi un autenticatore, cioè il componente che genera materialmente la passkey e utilizza la relativa chiave privata quando dobbiamo dimostrare la nostra identità.

L’autenticatore non è necessariamente un dispositivo separato: può essere integrato nel PC o nello smartphone, come avviene con Windows Hello e con i sistemi di autenticazione di Android e iOS, oppure può essere una security key esterna. Anche i sistemi che sincronizzano le passkey tra più dispositivi partecipano a questa architettura.

Durante la registrazione, è prevista – come abbiamo osservato in precedenza – la generazione di una coppia di chiavi: la chiave privata rimane protetta dall’autenticatore, mentre il sito memorizza quella pubblica.

Al momento del login il server genera un valore casuale, chiamato challenge, e lo invia al browser. L’autenticatore utilizza la chiave privata per produrre una firma crittografica legata a quella richiesta; il server usa la chiave pubblica per verificarla.

Una firma valida dimostra quindi che chi sta effettuando l’accesso controlla la chiave privata associata all’account. C’è inoltre un vantaggio essenziale contro il phishing: la credenziale WebAuthn è collegata alla relying party ovvero al sito per cui è stata creata. Una pagina fasulla ospitata su un altro dominio non può semplicemente convincere l’utente a consegnarle la passkey così come può accadere con una password digitata manualmente.

Attestation: quando il sito vuole sapere chi ha generato la credenziale

Tra le opzioni disponibili durante la creazione di una credenziale WebAuthn esiste il già citato parametro attestation.

Un servizio può, per esempio, utilizzare attestation: "none" oppure chiedere attestation: "direct". Con none, il servizio non pretende una prova verificabile della provenienza dell’autenticatore. Per molti normali utilizzi sul Web sapere che la credenziale funziona e che la firma è valida è sufficiente.

Con direct, invece, la relying party chiede informazioni di attestazione che possono permetterle di verificare quale classe di autenticatore abbia prodotto la credenziale.

In questo secondo scenario, quindi, il server non si limita a verificare se la firma crittografica sia valida o meno, può in aggiunta accertare se l’autenticatore che ha generato tale firma soddisfi i propri requisiti di sicurezza.

AAGUID e policy: cosa può controllare un sito

AAGUID (Authenticator Attestation Globally Unique Identifier) identifica una classe o un modello di autenticatore, non il singolo dispositivo dell’utente.

Associato a un’attestation verificabile e ai metadati FIDO, può consentire alla relying party di riconoscere il tipo di autenticatore e applicare una propria policy: per esempio accettare solo dispositivi appartenenti a determinate famiglie o con specifiche caratteristiche di sicurezza.

Un autenticatore open source perfettamente compatibile con WebAuthn potrebbe quindi essere rifiutato non perché la firma sia errata, ma perché il servizio non riesce a ricondurlo a una root of trust che considera valida.

Questo non significa però che WebAuthn riveli automaticamente al sito quale sistema operativo stiamo usando, se il bootloader è sbloccato o se Android è stato sostituito con LineageOS: authenticator attestation e device attestation sono concetti diversi. L’esclusione può avvenire indirettamente se una determinata piattaforma non offre un autenticatore capace di soddisfare la policy richiesta. Lo stesso principio vale negli ambienti aziendali con la Enterprise Attestation, dove l’obiettivo è proprio accettare soltanto autenticatori approvati dall’organizzazione.

Quindi è vero che le passkey sono una trappola?

Lo standard WebAuthn non obbliga un servizio ad accettare qualunque autenticatore capace di produrre una firma tecnicamente valida. Una relying party può verificare attestazioni, utilizzare informazioni sugli autenticatori e adottare proprie policy per decidere quali credenziali accettare. La possibilità di creare categorie di autenticatori ammessi e non è quindi reale: su questo il contenuto dell’articolo “Passkeys are a trap. Do not use them” corrisponde al vero.

La tesi sviluppata, tuttavia, va davvero troppo sopra le righe quando da questa possibilità si passa all’idea che le passkey consentano automaticamente a qualsiasi sito di controllare l’intero dispositivo dell’utente o che il loro destino inevitabile sia quello di imporre sistemi operativi e hardware approvati.

La normale authenticator attestation non equivale alla verifica completa della piattaforma; inoltre, l’attestation non è un requisito necessario per utilizzare normalmente le passkey.

Più che una “trappola” insita nella natura delle passkey, ci troviamo dinanzi a uno strumento di policy molto potente il cui impatto dipende da come i servizi decidono di utilizzarlo.

Le passkey restano preferibili alle password

Non ci sentiamo quindi di sottoscrivere l’invito a non usare le passkey, anzi. I vantaggi delle passkey rispetto all’uso delle password sono innegabili e sotto gli occhi di tutti: nessun segreto viene trasferito dal client al server, le credenziali non possono essere riutilizzate come una password e il legame con la relying party di ciascuna passkey (ovvero con ciascun sito sul quale si effettua il login…) offre una protezione formidabile contro molte forme di phishing.

L’attestation è comunque un punto che vale la pena tenere presente: in alcuni scenari, infatti, il servizio al quale si accede può decidere quali tecnologie ritiene sufficientemente affidabili.

Per una banca, un’infrastruttura critica o un’azienda che gestisce dispositivi propri possono esistere ragioni molto solide per adottare criteri stringenti.

Sarebbe invece assai più discutibile vedere normali servizi Internet rifiutare utenti soltanto perché utilizzano un autenticatore alternativo o non riconosciuto, pur perfettamente conforme agli standard.

Tra gli autenticatori WebAuthn/FIDO2 che un utente può usare ci sono Windows Hello su un PC Windows, una YubiKey 5 NFC o un’altra security key FIDO2 esterna, oppure gli autenticatori integrati nei sistemi mobili e i gestori di passkey supportati dalla piattaforma. Microsoft, per esempio, documenta esplicitamente l’uso di Windows Hello e delle FIDO2 Security Keys tramite WebAuthn; Windows 11 supporta inoltre plugin di terze parti per la gestione delle passkey: in un altro articolo parlavamo del login in Windows 11 con Bitwarden.

Il caso concreto più chiaro di policy selettiva è quello descritto da Yubico: un’azienda può decidere di accettare solo YubiKey 5 NFC e rifiutare qualsiasi altro autenticatore durante la registrazione. Con la normale attestation riesce a riconoscere marca e modello; con Enterprise Attestation può arrivare a identificare anche il singolo dispositivo aziendale, per esempio tramite numero di serie, e verificare se quella specifica chiave è approvata.