MFA: perché la sua app Google Authenticator la tradisce

Un cliente mi mostra fiero il suo telefono. Google Authenticator, una ventina di account dentro, backup sincronizzato. «Sono blindato.» Tre settimane prima, il suo account Google era servito da porta d’ingresso: una falsa email di condivisione documento, una pagina di login che assomigliava in modo impressionante a quella di Google, un codice a sei cifre ricopiato senza pensarci. L’attaccante non ha rotto niente. Il cliente gli ha porto il codice, in tempo reale, come si porgono le chiavi al parcheggiatore. E la sua «blindatura» era sincronizzata sull’account che era appena crollato.

La trappola abituale

«Ho attivato il 2FA, sono protetto.» È la frase che sento più spesso durante gli audit, ed è la più pericolosa del vocabolario della sicurezza personale. Non perché sia falsa in senso stretto — la MFAAutenticazione a più fattori: combinare due prove d'identità indipendenti per accedere.Vedi il glossario riduce davvero il rischio rispetto a una semplice password. Ma perché colloca in un’unica casella «protetto / non protetto» dei dispositivi che non hanno nulla a che vedere tra loro in termini di robustezza.

La MFA non è una categoria unica, è uno spettro. A un estremo, il codice via SMS, che crolla al primo SIM swapAttacco in cui un truffatore convince il proprio operatore a trasferire il numero su una SIM controllata da lui.Vedi il glossario di passaggio. Al centro, il TOTPCodice a 6 cifre generato ogni 30 secondi da un'app (Google Authenticator, Authy, ecc.).Vedi il glossario — quei codici a sei cifre che cambiano ogni trenta secondi, il famoso Google Authenticator. All’altro estremo, il FIDO2Standard di autenticazione forte tramite chiave crittografica hardware, resistente al phishing.Vedi il glossario, una chiave hardware o una passkeyImplementazione consumer di FIDO2: chiave di autenticazione memorizzata e sincronizzata da Apple/Google/Microsoft.Vedi il glossario che si rifiuta fisicamente di autenticarsi sul dominio sbagliato. Tra l’SMS e il FIDO2, ci sono due ordini di grandezza di differenza sulla resistenza al phishingAttacco di ingegneria sociale che spinge il bersaglio a fornire le proprie credenziali o eseguire codice.Vedi il glossario. Mettere tutto questo nello stesso sacco «2FA» è come dire «ho una serratura» senza precisare se è un chiavistello da bagno o un cilindro certificato.

La conseguenza pratica è doppia, ed entrambe le facce sono cattive. Da un lato, persone che si credono protette e non investono nella vera protezione, perché pensano di aver già spuntato la casella. Dall’altro, l’illusione che crolla nel momento peggiore — durante un attacco mirato, in viaggio, sull’account che pilota tutta la loro vita digitale. Il TOTP non è inutile. Ma venderlo come fine partita è la radice del problema.

Il modello di minaccia reale: ciò che supera il TOTP

Il malinteso di fondo è credere che il TOTP protegga contro il phishing. Non protegge. Protegge contro una cosa precisa — il furto di password senza interazione in tempo reale con la vittima — e basta. Di fronte a un attaccante che le parla nel momento in cui si connette, il codice a sei cifre è un fattore in più da ricopiare, non un muro.

Ecco la meccanica concreta, quella che vedo nei dossier. L’attaccante non costruisce una falsa pagina statica che raccoglie la sua password per rigiocarla più tardi. Monta un reverse-proxyAttacco in cui un attore si interpone in una comunicazione tra due parti che credono di essere in contatto diretto.Vedi il glossario tra lei e il vero servizio — è un attacco detto adversary-in-the-middle (AiTM). Lei arriva su una pagina che è, byte per byte, la vera pagina di login: non è una copia, è la vera pagina ritrasmessa in tempo reale. Lei digita la sua credenziale, il proxy la trasmette a Microsoft o Google. Il vero servizio chiede il codice TOTP. Lei lo digita. Il proxy lo trasmette anche. Il servizio convalida e rinvia un cookie di sessione autenticato — ed è quel cookie che l’attaccante cattura. Ha ora la sua sessione attiva. Il codice a sei cifre era già stato consumato; non gliene importa nulla, ha di meglio: è connesso come lei, senza dover ripassare dalla MFA.

Questa strumentazione non è riservata a Stati-nazione. Framework open source come EvilginxAttacco di ingegneria sociale che spinge il bersaglio a fornire le proprie credenziali o eseguire codice.Vedi il glossario fanno esattamente questo, chiavi in mano, con «phishlet» preconfigurati per Office 365, Google Workspace, Okta, i principali fornitori. Il kit di phishing AiTM si affitta ad abbonamento sui forum criminali — del «phishing-as-a-service», con hosting, certificato TLSProtocollo di cifratura del trasporto, base di HTTPS e della sicurezza web moderna.Vedi il glossario valido per il dominio esca e cruscotto per raccogliere le sessioni rubate. L’asticella tecnica per bypassare il suo TOTP è scesa al livello di uno script-kiddie motivato. Microsoft ha documentato campagne AiTM che hanno colpito decine di migliaia di organizzazioni. Non è né teorico, né raro.

Il dettaglio che fa male in questo scenario è che tutti i riflessi che le hanno insegnato per individuare il phishing falliscono qui. Il lucchetto TLS nella barra degli indirizzi? Presente — l’attaccante ha un vero certificato per il suo dominio esca. La pagina che «sembra vera»? È vera, ritrasmessa pixel per pixel. Il codice TOTP che lei digita «perché tanto è il sito giusto»? Transita. E anche la notifica push di convalida, presunta «più sicura» del TOTP, non risolve nulla: l’attaccante innesca la connessione legittima nel momento in cui lei convalida, quindi lei approva la sua sessione credendo di approvare la propria. È la «MFA fatigue» nella sua versione chirurgica. Tutto ciò che poggia su un essere umano che ricopia o approva un segreto al momento giusto è vulnerabile, perché l’essere umano non può distinguere il momento giusto da quello sbagliato quando il proxy è perfetto.

Bisogna anche uccidere un’idea ricevuta tenace: «il TOTP è matematicamente solido, quindi l’app TOTP è solida». Le due proposizioni non hanno nulla a che vedere. Sì, l’algoritmo della RFC 6238Codice a 6 cifre generato ogni 30 secondi da un'app (Google Authenticator, Authy, ecc.).Vedi il glossario è di cemento — un HMAC su un contatore temporale, niente da dire. Ma la robustezza di un fattore di autenticazione non si misura sulla forza del suo algoritmo; si misura su ciò che serve per aggirarlo in condizioni reali. E in condizioni reali, non si rompe l’HMAC: si intercetta il codice in transito, o si rubano i semi a riposo. L’algoritmo perfetto non protegge niente se il segreto che manipola trapela dai lati.

E questo è solo il vettore online. Il TOTP ha un secondo tallone d’Achille, più banale: il backup cloud. È la trappola del mio cliente in apertura. Quando lei sincronizza Google Authenticator con il suo account Google, o Authy con il suo account Authy, i suoi semi TOTP — i segreti che generano i codici — lasciano il suo telefono per vivere in un cloud. Da quel momento, il suo «secondo fattore» non è più indipendente dal primo: compromettere l’account cloud compromette l’insieme dei suoi codici in un solo movimento. Lei ha trasformato un fattore di possesso in un’estensione del suo account email. Il giorno in cui quell’account crolla — phishing, password riutilizzata, fuga — l’attaccante recupera l’intera cassaforte.

L’approccio giusto: gerarchizzare, poi spostare il critico verso FIDO2

La via d’uscita non è «elimini il TOTP». È «smetta di trattare tutti i suoi account allo stesso modo, e metta la vera protezione dove conta». Ponga prima la gerarchia di robustezza, dal peggiore al migliore: SMS, poi TOTP cloud, poi TOTP locale, poi FIDO2 hardware. Ogni gradino sale di un livello nella resistenza al phishing. L’SMS crolla al SIM swap. Il TOTP cloud crolla con l’account cloud. Il TOTP locale resiste al furto a distanza dei semi ma resta «phishabile» in tempo reale via AiTM. Il FIDO2, esso, rompe l’attacco AiTM per costruzione.

Perché il FIDO2 è diverso e non solo «migliore»: la crittografia di WebAuthnAPI del browser che consente l'autenticazione FIDO2 sui siti web.Vedi il glossario lega l’autenticazione al dominio. La chiave firma una risposta che include l’origine esatta del sito richiedente. Se lei è su login-microsoft.attaccante.com invece di login.microsoftonline.com, la firma non corrisponde, e la chiave rifiuta — senza che lei debba individuare alcunché, senza giudizio umano, senza «questo URL è strano?». Il segreto non lascia mai l’elemento hardware: non c’è codice da ricopiare, quindi nulla da intercettare nel proxy. È ciò che il CISA e il NISTIstituto americano che pubblica gli standard di riferimento in cybersicurezza (CSF, SP 800-*).Vedi il glossario chiamano una MFA «resistente al phishing», in opposizione a tutto il resto. La distinzione non è marketing, è strutturale.

La transizione pragmatica si articola in una regola: tutto ciò che può reimpostare il resto passa per primo. La sua email principale è la radice — è attraverso di essa che transitano tutte le reimpostazioni di password. La metta sotto FIDO2 prima di tutto il resto. Poi gli account finanziari, poi il gestore di password, poi le console di amministrazione se ne ha. Per il resto — le centinaia di account secondari dove FIDO2 non è proposto o non è giustificato — tenga del TOTP, ma locale, in un’app che non sincronizza i suoi semi in un cloud legato alla sua identità. Aegis su Android, Raivo o Ente Auth su iOS: semi cifrati sul dispositivo, export manuale cifrato per il backup, nessun backup automatico nell’account che il TOTP è presunto proteggere. E mai, mai il TOTP nello stesso gestore di password cloud delle password: altrimenti una sola compromissione dà il fattore 1 e il fattore 2.

Concretamente, l’ordine delle operazioni conta tanto quanto l’obiettivo, perché la migrazione è il momento in cui ci si chiude fuori da soli per maldestraggine. La sequenza che faccio applicare: prima, registro le due chiavi FIDO2 sull’account bersaglio mentre il vecchio metodo è ancora attivo — non si aggiunge mai un fattore forte eliminando il vecchio nello stesso gesto. Poi testo una disconnessione / riconnessione completa con ciascuna delle due chiavi, separatamente, per verificare che nessuna sia stata registrata a metà. Poi recupero e conservo offline i codici di recupero che il servizio genera — su carta, non nel gestore che dipende esso stesso da questo account. E solo allora tolgo i metodi deboli: SMS, OTP e-mail, e se del caso il TOTP diventato ridondante. Saltare una di queste tappe significa o ritrovarsi fuori, o lasciare una porta debole aperta «provvisoriamente» — e il provvisorio dura.

Il versante TOTP locale merita la stessa disciplina, perché il suo punto debole non è l’attacco ma la perdita. Un’app locale che non sincronizza niente è esattamente ciò che si vuole dal lato sicurezza — ed esattamente ciò che la condanna il giorno in cui il telefono finisce in un water se non ha un backup. La parata si articola in due gesti: un export cifrato dei semi (Aegis lo fa in AES, protetto da una passphrase forte) conservato su un supporto offline, e la conservazione dei codici di recupero di ogni servizio al momento dell’arruolamento. Non ha bisogno di un cloud per sopravvivere alla perdita di un dispositivo; ha bisogno di un export cifrato che controlla e di una passphrase che solo lei conosce.

Resta la questione delle passkey, perché gliele venderanno come la risposta universale. Una passkeyImplementazione consumer di FIDO2: chiave di autenticazione memorizzata e sincronizzata da Apple/Google/Microsoft.Vedi il glossario è del FIDO2 sotto un nome di massa: stessa resistenza al phishing per legame al dominio, stessa crittografia WebAuthnAPI del browser che consente l'autenticazione FIDO2 sui siti web.Vedi il glossario. La sfumatura è nell’archiviazione. Una passkey sincronizzata in iCloud o nel suo account Google eredita la sicurezza di quell’account — il che va benissimo per i suoi account ordinari, e discutibile per la manciata di account la cui compromissione è precisamente lo scenario che vuole escludere. Per quegli account, preferisca una passkey non sincronizzata conservata sulla chiave hardware stessa, o conservi due chiavi FIDO2 fisiche. Per tutto il resto, la passkey sincronizzata è un eccellente compromesso robustezza / praticità, e ampiamente superiore al TOTP.

Ultimo punto che non è opzionale: due chiavi FIDO2 minimo. Una che porta con sé, una di backup in un luogo sicuro, entrambe registrate su ogni account critico. La modalità di guasto classica del FIDO2 non è l’attacco, è la perdita della chiave unica che la chiude fuori. Una chiave sola è un punto unico di guasto. Due chiavi sono resilienza.

Cosa comporta concretamente

Errori che si vedono di continuo

• Sincronizzare i propri semi TOTP nel cloud dell’account che proteggono. Google Authenticator backupato su Drive, Authy bloccato via SMS: il secondo fattore non è più indipendente dal primo. Una compromissione, tutto crolla.
• Credere che il TOTP fermi il phishing. Ferma il furto di password rigiocato più tardi. Non fa niente contro un reverse-proxy AiTM che ritrasmette il suo codice in tempo reale. La distinzione è tutta la differenza.
• Mescolare password e TOTP nello stesso gestore cloud. Pratico, ed è il problema: fattore 1 e fattore 2 nello stesso paniere, una sola fuga li dà entrambi.
• Una sola chiave FIDO2, senza riserva. Il giorno in cui la perde, è chiuso fuori — o peggio, riapre in emergenza un metodo debole «giusto per il tempo di» e non lo richiude mai.
• Attivare FIDO2 sugli account critici ma lasciare l’SMS come ripiego. Un attaccante non attacca la sua chiave: prende l’opzione più debole ancora disponibile. Finché il ripiego debole esiste, il FIDO2 non serve a niente.
• Dimenticare il percorso di recupero. Lei ha irrobustito la connessione, non la reimpostazione. L’help desk che ripristina una MFA su tre informazioni pubbliche annulla tutto il lavoro.

Checklist azionabile

• N1 Elencare gli account critici (email principale, banca, gestore di password, console admin)
• N1 Disattivare il backup/sincronizzazione cloud dell'app TOTP esistente
• N1 Migrare il TOTP verso un'app locale senza sync cloud (Aegis, Raivo, Ente Auth)
• N2 Acquistare due chiavi FIDO2 e registrare entrambe sull'email principale
• N2 Separare fisicamente le password e i semi TOTP (supporti distinti)
• N2 Spostare banca e gestore di password verso FIDO2 quando disponibile
• N3 Disattivare l'SMS e l'OTP e-mail come ripiego sugli account passati a FIDO2
• N3 Provisionare una chiave FIDO2 di riserva conservata fuori dal domicilio principale
• N3 Verificare e irrobustire i percorsi di recupero dell'account (verifica di identità forte)

Per approfondire

La distinzione tra MFA «phishabile» e MFA resistente al phishing non è un’opinione: è posta nero su bianco dal NIST (SP 800-63B) e dettagliata dal CISA nella sua guida all’implementazione della MFA resistente al phishing — i due riferimenti da leggere se deve argomentare una migrazione internamente. Per capire cosa garantisce FIDO2 crittograficamente, vada a vedere le specifiche della FIDO Alliance; per il funzionamento esatto del TOTP e i suoi limiti, la RFC 6238 è breve e leggibile. E se dubita ancora che l’attacco AiTM sia alla portata di un attaccante ordinario, la documentazione pubblica di Evilginx basta a farsi un’idea del livello di sforzo reale — cioè basso.