MFA resistente al phishing: perché non ogni doppio fattore è uguale

L'autenticazione a più fattori non è una cosa sola. La distanza tra un codice usa e getta inviato via SMS e una passkey ancorata all'hardware è la differenza tra rallentare un aggressore e fermarlo del tutto. È la distinzione tra MFA phishabile e MFA resistente al phishing.

Perché gran parte della MFA è ancora phishabile

Il problema di codici e richieste push è che il secondo fattore è un segreto condiviso che l'essere umano può cedere. Se un utente può leggere un codice e digitarlo in una pagina, può essere indotto a digitarlo nella pagina di un aggressore.

• Codici SMS / TOTP — un proxy aggressore nel mezzo (AiTM) come Evilginx presenta un clone di login perfetto, inoltra le credenziali e l'OTP in tempo reale e cattura il cookie di sessione risultante. Il codice valido non serve a nulla.
• Notifiche push — vulnerabili alla stanchezza da MFA / bombardamento di richieste: approvazioni ripetute finché un utente stanco tocca «Approva».
• SIM swapping — sposta il numero della vittima sulla SIM di un aggressore, sconfiggendo del tutto gli SMS.

La corrispondenza dei numeri e il geo-contesto nel push aiutano, ma sono mitigazioni su un design fondamentalmente phishabile.

Cosa rende la MFA resistente al phishing

La MFA resistente al phishing toglie l'essere umano dalla decisione di fiducia. Contano due proprietà:

• Ancoraggio all'origine — la credenziale è legata crittograficamente all'esatta origine web per cui è stata registrata. Un dominio simile o proxy semplicemente non corrisponde, quindi l'autenticazione fallisce in silenzio.
• Nessun segreto condiviso in transito — l'autenticazione usa un challenge-response con una chiave privata che non lascia mai il dispositivo.

Gli standard che lo forniscono:

• FIDO2 / WebAuthn — lo standard di browser e piattaforma per l'autenticazione a chiave pubblica.
• Passkey — credenziali FIDO2, o legate al dispositivo (chiave di sicurezza hardware, ad es. YubiKey) o sincronizzate (salvate su un ecosistema di fornitore come Apple, Google o un gestore di password).
• PIV / smart card (x.509) — l'approccio consolidato di aziende ed enti pubblici.

Perché i proxy AiTM ci falliscono contro

Utente → phish.example (proxy dell'aggressore) → real.example

L'asserzione WebAuthn è firmata sull'origine che il browser vede:
  clientDataJSON.origin = "https://phish.example"
La credenziale è stata registrata per "https://real.example"
→ discordanza di origine → l'authenticator/RP rifiuta l'asserzione

Non c'è alcun codice da far inoltrare all'utente né alcun cookie che il proxy possa raccogliere, perché il login non riesce mai contro l'origine sbagliata. Lo impone il browser — non l'essere umano.

Distribuirla senza rompere le cose

Priorità per rischio. Iniziate da amministratori, finanza, dirigenti e chiunque abbia accesso ai sistemi più preziosi. Sono gli account che i kit AiTM prendono di mira per primi.

Pianificate il recupero dell'account. Il recupero è il nuovo ventre molle — se una chiave persa ripiega su SMS o su una chiamata all'help desk, avete reintrodotto il percorso phishabile. Richiedete due authenticator registrati per utente (ad es. una chiave di sicurezza più una passkey di piattaforma) e irrobustite la verifica dell'identità all'help desk.

Gestite parchi misti. Le passkey sincronizzate facilitano il rollout su dispositivi personali e mobili; le chiavi legate al dispositivo si adattano a scenari ad alta garanzia e condivisi/kiosk. Molte organizzazioni usano entrambe.

Scandite la migrazione:

1. Abilitate FIDO2/passkey accanto alla MFA esistente.
2. Registrate un secondo fattore e promuovete campagne di enrollment.
3. Portate i ruoli privilegiati a resistente al phishing obbligatorio.
4. Rimuovete SMS e voce come fattori.
5. Estendete il requisito di resistenza al phishing a tutta l'organizzazione tramite accesso condizionale.

Puntate a rendere il resistente al phishing obbligatorio, non solo disponibile. Finché esiste un ripiego phishabile, gli aggressori vi spingono gli utenti — una tecnica nota come downgrade della MFA.

Come aiuta GottaPhish

La MFA phishabile — OTP e push — dà un falso senso di sicurezza mentre lascia un divario reale che gli aggressori sfruttano attivamente; possedere la tecnologia non lo chiude. GottaPhish e il suo team di esperti vi aiutano a costruire il business case e a eseguire il rollout: le nostre simulazioni in stile AiTM dimostrano, in modo sicuro e misurabile, come la MFA a OTP e push cade davanti a un proxy reale, dando alla dirigenza la prova per finanziare la MFA resistente al phishing. Da lì i nostri esperti guidano l'adozione di FIDO2/passkey al vostro fianco — dando priorità ai ruoli ad alto rischio, pianificando l'enrollment a doppio authenticator e il recupero, e riferendo sull'adozione insieme alle metriche di clic e segnalazione — e aiutano a interpretare i risultati, così potete dimostrare che il divario phishabile si sta davvero chiudendo.