La maggior parte dei confronti tra queste due opzioni si riduce a comodità contro sicurezza, con la vaga affermazione che le chiavi sono "più sicure". Esiste una risposta più precisa, ed è scritta in uno standard.
La frase che chiude la questione phishing
NIST SP 800-63B, sezione 5.2.5, è diretto in proposito. Gli autenticatori che comportano l'inserimento manuale di un output dell'autenticatore, come gli autenticatori out-of-band e OTP, non devono essere considerati resistenti all'impersonificazione del verificatore, perché l'inserimento manuale non lega l'output dell'autenticatore alla specifica sessione autenticata.
La stessa sezione spiega l'attacco anziché lasciarlo implicito: in un attacco machine-in-the-middle, un verificatore impostore potrebbe ritrasmettere l'output dell'autenticatore OTP al verificatore reale e autenticarsi con successo.
È tutto qui il meccanismo. Il tuo codice a sei cifre è corretto. È semplicemente corretto ovunque, anche su una pagina che si limita a somigliare a quella della tua banca.
Perché il legame è la vera differenza
Lo standard definisce la resistenza all'impersonificazione del verificatore come lo stabilire un canale protetto e autenticato con il verificatore, per poi legare in modo forte e irreversibile un identificatore di canale all'output dell'autenticatore, ad esempio firmando i due valori insieme con una chiave privata.
Leggi questo alla luce di ciò che ogni metodo fa fisicamente.
Un'app di autenticazione genera un numero a partire da un segreto condiviso e da un orologio. Non viene mai a sapere su quale sito ti trovi. Sei tu il livello di trasporto, e puoi essere dirottato.
Una chiave di sicurezza firma una sfida insieme all'identità della sessione. La FIDO Alliance descrive le passkey come basate su tecniche standard di crittografia a chiave pubblica per fornire un'autenticazione resistente al phishing. Non c'è alcun numero da leggere ad alta voce, e quindi nulla che un attaccante possa ritrasmettere.
Come appare l'attacco dal tuo lato
L'astrazione nasconde quanto tutto ciò sia ordinario, quindi vale la pena ripercorrerlo.
Ricevi un messaggio sul tuo account. Il link porta a una pagina che si visualizza correttamente, perché il server dell'attaccante sta recuperando la pagina reale e la sta ritrasmettendo. Inserisci la tua password. Il server dell'attaccante la invia subito al sito reale. Il sito reale chiede un secondo fattore, quindi la pagina falsa lo chiede anche a te.
Apri la tua app e leggi sei cifre. Il server dell'attaccante le inserisce sul sito reale entro la stessa finestra di trenta secondi. Il sito reale vede una password valida e un codice valido, ed emette una sessione. Ora l'attaccante detiene quella sessione.
Nota cosa non è mai successo. Nulla è stato violato, nessun segreto è stato rubato dal tuo telefono, e la tua app si è comportata esattamente come previsto. Il codice era autentico. È stato semplicemente usato in un posto in cui non intendevi usarlo, e né tu né l'app avevate modo di accorgervene, perché il codice non porta con sé alcuna informazione sulla propria destinazione.
Ripeti la stessa sequenza con una chiave di sicurezza e si ferma al secondo fattore. La chiave non produce un numero da ritrasmettere. Firma una risposta legata al sito che sta davvero chiedendo, quindi il server dell'attaccante riceve qualcosa che funziona solo sul proprio dominio, il che per lui è inutile.
Dove nemmeno una chiave aiuta
Essere precisi sui limiti conta quanto esserlo sui punti di forza, perché una chiave non è uno scudo universale.
Non protegge una sessione già emessa. Se un malware sulla tua macchina ruba un cookie di sessione dopo che ti sei autenticato legittimamente, il passaggio di login è alle tue spalle e la chiave non è più coinvolta.
Non protegge il percorso di recupero. Un account che può essere reimpostato via email o da un operatore dell'assistenza è forte quanto quel percorso. È esattamente per questo che l'account email è il primo da proteggere, e per cui le domande di recupero dell'account restano un bersaglio facile.
Non protegge ciò che vede un dispositivo compromesso. Se l'endpoint è completamente compromesso, l'attaccante è dentro la sessione autenticata insieme a te.
Non copre i servizi che non la supportano. È il limite pratico per la maggior parte delle persone, ed è la ragione per cui una chiave è un'aggiunta a un'app di autenticazione anziché un suo sostituto.
La sfumatura che quasi tutti i confronti perdono
È qui che molta letteratura sulla sicurezza esagera, quindi vale la pena dirlo chiaramente.
La resistenza all'impersonificazione del verificatore è richiesta solo ad AAL3 nel quadro NIST. Ad AAL1 e AAL2 non è obbligatoria. Un'app TOTP è quindi un secondo fattore conforme per una parte molto ampia degli account ordinari, e resta un netto miglioramento rispetto ai codici via SMS o all'assenza di un secondo fattore.
L'inquadramento onesto non è quindi "le app sono rotte". È che le app hanno una debolezza specifica, il phishing in tempo reale, e che questa debolezza è strutturale anziché un difetto di una particolare app. Nessun aggiornamento della tua app di autenticazione la risolverà, perché il divario sta nel passaggio di inserimento manuale stesso.
Scegliere senza pensarci troppo
La decisione discende da ciò che ottiene un attaccante se un dato account cade.
Usa una chiave di sicurezza dove una compromissione è irrecuperabile. Il tuo account email per primo, perché è il percorso di reimpostazione della password per tutto il resto. Poi il tuo gestore di password. Poi qualsiasi servizio finanziario che supporti le chiavi.
Tieni l'app per l'ampiezza. La maggior parte dei servizi ancora non supporta le chiavi di sicurezza. Un'app di autenticazione su quegli account è di gran lunga meglio di niente, e non costa nulla.
Non usare una chiave sola senza alternativa. Registrane una seconda, oppure conserva i codici di recupero stampati e custoditi offline. Perdere la tua unica chiave è un blocco autoinflitto, ed è un guasto più comune dell'essere vittima di phishing.
Se stai decidendo quale chiave acquistare, confrontiamo i modelli attuali nel nostro confronto delle chiavi di sicurezza hardware.
A confronto
| App di autenticazione | Chiave di sicurezza | |
|---|---|---|
| Resiste al phishing in tempo reale | No, secondo NIST 5.2.5 | Sì, risposta legata alla sessione |
| Cosa maneggi | Un codice che leggi e ridigiti | Nulla, firma il dispositivo |
| Richiesta ad AAL3 | Non sufficiente da sola | Soddisfa il requisito |
| Funziona sulla maggior parte dei servizi | Sì | Solo dove è supportata |
| Costo | Gratuita | Circa da 25 a 60 unità monetarie per chiave |
| Principale modalità di guasto | Vieni ingannato e inserisci un codice valido | Perdi la chiave senza averne registrata una di riserva |
| Recupero in caso di perdita | Reinstallazione da un backup dei seed | Registrare una seconda chiave, o i codici di recupero |
Le ultime due righe sono quelle che si sottovalutano. Il rischio reale dominante con un'app è essere indotti a usarla correttamente nel momento sbagliato. Il rischio reale dominante con una chiave è perderla dopo averne registrata una sola.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Conserva i codici di recupero dove li avrai ancoraI codici di recupero sono ciò che ti fa rientrare quando una chiave va persa. Un gestore di password li tiene fuori dal dispositivo che stai cercando di recuperare, ed è proprio questo il punto.→In breve
La questione del phishing non è materia di opinione. Il NIST afferma che gli autenticatori OTP non possono essere considerati resistenti all'impersonificazione del verificatore, e spiega perché: l'inserimento manuale non lega il codice alla sessione. Una chiave di sicurezza firma la sessione stessa, quindi non c'è nulla da ritrasmettere.
Ma il requisito si applica ad AAL3, non ovunque. Un'app di autenticazione resta un secondo fattore legittimo per la maggior parte degli account. Metti le chiavi dove una perdita sarebbe irrecuperabile, tieni l'app per la coda lunga, e assicurati di avere una via di rientro.
Le definizioni e i requisiti qui descritti sono tratti dalla NIST Special Publication 800-63B, e la caratterizzazione delle passkey dal materiale della stessa FIDO Alliance, entrambi verificati al momento della stesura. Gli standard vengono rivisti; verifica sul testo corrente prima di basarti su una clausola specifica. I link commerciali riportano l'attributo rel="sponsored nofollow"; può essere applicata una commissione di affiliazione senza costi aggiuntivi per te.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Un gestore con 2FA e passkey integrate → NordPassSalva TOTP e passkey · XChaCha20 · piano gratuito→Domande frequenti
Una chiave di sicurezza è davvero più resistente al phishing di un'app di autenticazione?
Su questo punto specifico lo standard non lascia ambiguità. Il NIST SP 800-63B afferma che gli autenticatori che comportano l'inserimento manuale di un output, come gli autenticatori out-of-band e OTP, non devono essere considerati resistenti all'impersonificazione del verificatore, perché l'inserimento manuale non lega l'output alla specifica sessione autenticata. Un autenticatore crittografico firma un identificatore di canale insieme alla propria risposta: è ciò che fa una chiave di sicurezza ed è ciò che un codice a sei cifre non può fare.
Perché digitare il codice conta così tanto?
Perché il codice non ha idea di dove lo stai digitando. Il NIST descrive l'attacco in modo diretto: un verificatore impostore può ritrasmettere l'output OTP al verificatore reale e autenticarsi con successo. Una pagina di login falsa raccoglie il tuo codice e lo usa entro la sua finestra di validità. Il codice è valido, il sito no, e nulla nel processo rileva la differenza.
Significa che le app di autenticazione non sono sicure?
No, ed è bene essere precisi. La resistenza all'impersonificazione del verificatore è richiesta solo ad AAL3 nel quadro NIST. Ad AAL1 e AAL2 non è obbligatoria, quindi un'app TOTP resta un secondo fattore conforme per una larga parte degli account ordinari. È un miglioramento enorme rispetto agli SMS e rispetto all'assenza di un secondo fattore. Il divario è specifico: riguarda il phishing in tempo reale, non la solidità generale del metodo.
Cosa rende una chiave di sicurezza resistente dove un codice non lo è?
La credenziale è crittografica anziché un numero trascritto. La FIDO Alliance descrive le passkey come basate su tecniche standard di crittografia a chiave pubblica per fornire un'autenticazione resistente al phishing. La risposta è prodotta dal dispositivo ed è legata alla sessione, quindi non c'è nulla da leggere ad alta voce e nulla che un attaccante possa ritrasmettere.
Dovrei usarle entrambe?
Di solito è la risposta pratica. Usa una chiave di sicurezza sugli account che sarebbe peggio perdere, tipicamente l'email e il gestore di password, dato che l'email è il percorso di reimpostazione per tutto il resto. Tieni un'app di autenticazione per i molti servizi che non supportano le chiavi. Registra una seconda chiave o conserva i codici di recupero offline, perché una chiave sola senza alternativa è a sua volta un rischio.
