Cos'è l'MFA resistente al phishing?

L'MFA resistente al phishing è una forma di autenticazione a più fattori in cui il secondo fattore è legato per via crittografica al dominio del servizio, così che una credenziale carpita su un sito clone non sia riutilizzabile altrove. In pratica si parla di passkey e chiavi hardware FIDO2/WebAuthn: la firma prodotta vale solo per l'origine che l'ha chiesta, ed è quel legame, non il posto in cui la chiave è custodita, a fare la differenza. È la distinzione che manca nella frase più ricorrente nelle riunioni di sicurezza, "abbiamo attivato l'MFA, siamo a posto", che è una mezza verità. Un codice via SMS, un TOTP generato da un'app, cioè un codice a tempo, o una notifica push da approvare aggiungono un ostacolo, ma restano segreti che una persona può consegnare a un sito falso o approvare per stanchezza. E il furto del cookie di sessione scavalca il discorso: chi ruba la sessione dopo l'accesso non ha bisogno di alcun fattore, perché arriva già autenticato.

Leggi anche: Phishing · Inganno che spinge una persona a consegnare credenziali, dati o denaro fingendo un interlocutore legittimo.

Perché SMS, TOTP e push non bastano

L'attacco che li batte tutti e tre si chiama adversary in the middle: la vittima riceve il link di una pagina di login identica all'originale, ma dietro c'è un proxy che gira le credenziali al servizio vero in tempo reale. L'utente digita password e codice, il proxy li inoltra, l'accesso riesce e l'attaccante incassa il cookie di sessione. Il codice è valido, il secondo fattore ha funzionato, e l'accesso è comunque compromesso. Un password manager che compila le credenziali solo sul dominio registrato è un primo freno, perché sulla pagina clonata non propone nulla, ma non serve se l'utente le digita a mano. Le notifiche push aggiungono un problema di ergonomia: bombardare una persona di richieste alle due di notte finisce prima o poi con un tocco su "approva". Gli SMS portano in dote il rischio di sostituzione della SIM, che non richiede alcuna abilità informatica ma solo un documento falso allo sportello di un operatore.

Cosa rende un fattore davvero resistente

Il meccanismo è il legame con l'origine. Il browser passa alla chiave l'indirizzo esatto del sito che sta chiedendo l'autenticazione, e la chiave firma solo per quello: su un dominio diverso, anche somigliante di una lettera, non produce nulla di utile. Lo standard che descrive il meccanismo è WebAuthn del W3C, mentre le linee guida sull'identità digitale del NIST, oggi alla SP 800-63B-4 del luglio 2025, non prescrivono una tecnologia: chiedono una proprietà, la resistenza all'impersonificazione del verificatore, al livello di garanzia dell'autenticazione più alto, quello che la 800-63B chiama AAL3. WebAuthn è una delle implementazioni che la soddisfano, e la differenza non è pedanteria: significa che a un fornitore si chiede quale proprietà garantisce, non quale sigla ha messo nel listino. La conseguenza operativa è che su questo vettore la formazione smette di dover insegnare a riconoscere una pagina falsa, perché non c'è più un segreto che l'utente possa consegnare. Non sparisce del tutto: restano gli inganni che non passano da una pagina di login, cioè il consenso concesso a un'applicazione terza e le richieste di approvare un codice di accesso generato altrove, dove la vittima si autentica sul sito vero e consegna comunque una sessione.

Va detta però una cosa che il marketing salta, perché riguarda il caso più diffuso. "La chiave privata non lascia il dispositivo" vale per un authenticator hardware, la chiavetta fisica che si infila nella porta USB, non per le passkey sincronizzate di Apple e Google, che sono quelle che la maggior parte delle persone si ritrova attive senza averle scelte. Lì il legame con l'origine è identico, quindi la resistenza al phishing resta intera; ma la custodia della chiave passa dal portachiavi cloud dell'account, e la sicurezza di quell'account diventa la sicurezza di tutte le passkey che contiene. È uno spostamento del problema, non una sua eliminazione, ed è la ragione per cui su chi amministra il dominio conviene una chiave fisica invece di una passkey sincronizzata.

Il caso di un'azienda con Microsoft 365 e VPN

Uno scenario ricorrente nella manifattura: posta e file su cloud, accesso ai gestionali via VPN, MFA con notifica push attivo per tutti da due anni. Il primo accesso illecito arriva da una finta pagina di rinnovo password inviata all'ufficio acquisti, e la sessione rubata basta a leggere lo scambio di email con un fornitore e a inserirsi in una trattativa di pagamento. La correzione non è "più formazione": è passkey obbligatoria per chi tocca pagamenti e amministrazione, sessioni corte legate a un dispositivo aziendale registrato, e la disattivazione dei protocolli di posta legacy che aggirano l'MFA per costruzione.

Perché conta per chi decide

Il fattore resistente al phishing chiude il vettore più sfruttato contro gli account umani, ma non copre il furto di sessione a valle né le identità applicative, che non hanno un dito da appoggiare su una chiave: quelle vanno governate come identità non umane. Per questo l'MFA vive dentro un impianto Zero Trust e non al posto suo, e per questo la domanda utile a un fornitore non è "c'è l'MFA?" ma "su quali gruppi è resistente al phishing, e cosa accade a una sessione già rubata?".