2FA non basta: come gli hacker aggirano l'autenticazione a due fattori

Si parla sempre più spesso di accantonare le password perché l’autenticazione basata su credenziali è ormai considerata vecchia, poco sicura ed esposta a un ampio ventaglio di possibili attacchi. Come abbiamo spiegato nell’articolo su quanto serve davvero per hackerare le password, l’autenticazione a due fattori (2FA) è una delle soluzioni universalmente più apprezzate che però non sostituisce le password ma introduce un livello di sicurezza aggiuntivo (se ben configurata e utilizzata).

L’autenticazione a due fattori è spesso percepita dagli utenti come una funzionalità “uniforme”, ma in realtà non è uno standard monolitico. È più corretto considerarla come un modello architetturale, declinato attraverso diversi protocolli, algoritmi e implementazioni.

2FA: modello concettuale vs standard tecnici

La 2FA, di per sé, non è uno standard formalizzato e universalmente approvato. È una categoria di autenticazione multifattoriale (MFA) che richiede almeno due fattori indipendenti.

Un fattore di autenticazione è una evidenza verificabile e indipendente che contribuisce a dimostrare l’identità di un utente. Il termine “indipendente” è cruciale: affinché più fattori aumentino realmente la sicurezza, devono appartenere a categorie diverse e non essere derivabili l’uno dall’altro.

Dal punto di vista normativo, anche il NIST (National Institute of Standards and Technology) statunitense definisce i fattori come elementi distinti che devono essere compromessi separatamente per violare un sistema di autenticazione.

Fattori: le tre categorie fondamentali

I fattori sono classificati in tre macro-categorie, ciascuna con proprietà di sicurezza differenti.

1. Knowledge factor (“qualcosa che conosci“). Appartengono a questa categoria password, PIN, passphrase o risposte a domande segrete. È il fattore più diffuso ma anche il più debole, perché: può essere riutilizzato, può essere intercettato (phishing, keylogger), è soggetto a attacchi brute force (come abbiamo visto nell’articolo citato in apertura) o credential stuffing, tecnica di attacco informatico in cui vengono utilizzate automaticamente combinazioni di credenziali (nome utente e password) rubate da altre violazioni per tentare l’accesso a diversi servizi online, sfruttando il fatto che molte persone riutilizzano le stesse password su più piattaforme.
2. Possession factor (“qualcosa che possiedi“). Rappresenta un oggetto in possesso dell’utente: smartphone con app OTP (es. Google Authenticator), token hardware, smart card o chiavi come YubiKey. È un fattore che introduce un elemento più robusto, ma non è immune da attacchi: furto fisico del dispositivo; compromissione software (malware); duplicazione (SIM swapping, clonazione token in alcuni contesti). La sua sicurezza dipende molto da come è protetto il segreto associato (secure enclave, TPM, ecc.).
3. Inherence factor (“qualcosa che sei“). Include caratteristiche biometriche come impronta digitale, riconoscimento facciale, scansione dell’iride. Questo fattore ha proprietà uniche, ma introduce problematiche specifiche: non è revocabile (non puoi “cambiare” impronta digitale); può avere falsi positivi/negativi; richiede hardware affidabile e protezione dei template biometrici.

Indipendenza dei fattori: il vero requisito di sicurezza

Non basta utilizzare due fattori qualsiasi: devono essere indipendenti sia logicamente che operativamente.

Facciamo un esempio concreto: se l’utente usa una password (classico accesso combinato con l’username) su un certo dispositivo e sullo stesso dispositivo gestisce l’OTP (One-Time Password) ovvero il secondo fattore usato per l’autenticazione, l’eventuale presenza di un malware che avesse infettato il dispositivo stesso può portare alla sottrazione di entrambe le informazioni. L’indipendenza è quindi compromessa.

Un sistema robusto dal punto di vista della 2FA deve quindi garantire che la compromissione di un fattore non implichi automaticamente la compromissione dell’altro; i canali di trasmissione siano separati; i segreti non siano derivabili tra loro.

Fattori espliciti e fattori impliciti

Nei sistemi moderni si delinea inoltre una distinzione meno evidente ma importante:

• Fattori espliciti: inseriti attivamente dall’utente (password, OTP).
• Fattori impliciti: valutati dal sistema senza interazione diretta.

I fattori impliciti includono ad esempio il fingerprinting del dispositivo, indirizzo IP e geolocalizzazione: tramite queste informazioni, il sistema di autenticazioni può adattarsi automaticamente all’uso lato client attivando una verifica a più fattori “invisibile”. Se un utente si collega sempre da indirizzi IP che segnalano l’uso del dispositivo client da una certa area geografica, il tentativo di accesso “dall’altra parte del mondo” è considerato sospetto. Così come l’uso di un dispositivo mai visto prima.

Principali standard coinvolti nella 2FA

I meccanismi che regolano il funzionamento dei sistemi di autenticazione a due fattori possono basarsi su standard ben definiti oppure su implementazioni custom. I principali standard coinvolti sono:

TOTP (Time-based One-Time Password) – definito in IETF RFC 6238;
HOTP (HMAC-based One-Time Password) – definito in IETF RFC 4226;
FIDO2 / WebAuthn – sviluppati dalla FIDO Alliance;
OATH (Initiative for Open Authentication) – framework per OTP interoperabili.

Questi standard definiscono come generare, validare e sincronizzare i fattori, ma non impongono come debbano essere integrati all’interno di un servizio. Di conseguenza, ogni piattaforma può implementare la 2FA con variazioni anche significative.

Come funzionano gli standard della 2FA nella pratica

Nel concreto, standard come TOTP, HOTP o FIDO2 non restano concetti teorici, ma si traducono in flussi di autenticazione molto diversi tra loro, che l’utente percepisce come azioni semplici – inserire un codice, approvare una notifica, usare l’impronta – ma che lato server implicano logiche ben distinte.

App di autenticazione (TOTP): codici sincronizzati nel tempo

Quando si utilizza un’app come Google Authenticator, si sta sfruttando TOTP. Durante l’attivazione della 2FA, il servizio genera un segreto condiviso e lo trasferisce all’app tramite QR code: da quel momento, server e dispositivo possiedono la stessa chiave segreta e sono in grado di calcolare in autonomia codici temporanei sincronizzati sul tempo.

In fase di login, dopo la verifica della password, il server richiede il codice OTP. L’utente lo legge dall’app e lo inserisce, mentre il server lo ricalcola in locale, in maniera indipendente, per verificare che corrisponda. Non avviene alcuna trasmissione del segreto durante questo processo: tutto si basa su un calcolo matematico.

È un approccio è standardizzato e interoperabile, ma presenta un limite evidente: il codice può essere intercettato o inserito in un contesto malevolo (ad esempio una pagina Web confezionata da un aggressore), rendendolo vulnerabile ad attacchi phishing in tempo reale.

Come viene generato un codice TOTP

Come abbiamo visto in precedenza, ogni codice TOTP è generato a partire da due elementi fondamentali: un segreto condiviso tra server/dispositivo e il tempo corrente.

TOTP=Truncate(HMAC(K,T))

K è il segreto generato lato server dal servizio al momento dell’attivazione della 2FA. Tale segreto è conservato lato server e nell’app authenticator dell’utente.

Per calcolare TOTP si prende il tempo corrente T (sono previste finestre della durata massima di 30 secondi) e lo si usa come input di una funzione crittografica HMAC insieme con il segreto K. Un’altra funzione apposita “tronca” il risultato per ottenere un codice numerico (di solito a 6 cifre).

Il calcolo è effettuato sia lato client che lato server: se il codice introdotto dall’utente è quello che il server attende (perché correlato a sua volta al segreto K), allora l’autenticazione è valida.

SMS ed email OTP: codici generati e trasmessi

Quando il codice arriva via SMS o email, il funzionamento cambia radicalmente. In questo caso non si utilizza un meccanismo standard come TOTP, ma una logica interamente gestita dal servizio.

Il server genera un codice casuale, lo associa temporaneamente all’utente o alla sessione e lo invia tramite un canale esterno. L’autenticazione si completa solo se il codice inserito coincide con quello memorizzato e rispetta i vincoli di validità.

La sicurezza dipende in questo caso meno dall’algoritmo e molto di più dall’integrità del canale di trasmissione e dalla gestione lato server. È un sistema semplice e diffuso, ma più esposto a intercettazioni e attacchi come il SIM swapping.

Notifiche push: autenticazione asincrona

Nei sistemi basati su notifiche push, il flusso diventa più fluido per l’utente. Dopo aver inserito la password, il server invia una richiesta al dispositivo registrato, che arriva tramite notifica via app.

L’utente riceve un messaggio con informazioni sul tentativo di accesso e può approvarlo o rifiutarlo con un semplice tocco. A quel punto, il dispositivo invia una risposta autenticata al server, spesso accompagnata da dati contestuali come posizione o tipo di dispositivo.

Non esiste più un codice da digitare: l’interazione è asincrona e mediata dall’applicazione. Questo migliora l’esperienza d’uso, ma introduce nuove criticità, soprattutto legate al comportamento umano, come l’approvazione involontaria di richieste ripetute (MFA fatigue).

FIDO2 / WebAuthn: autenticazione crittografica senza OTP

Con FIDO2 e WebAuthn si abbandona completamente il modello basato sui codici. Durante la registrazione, il dispositivo (ad esempio una chiavetta Yubikey) genera una coppia di chiavi crittografiche: la chiave privata resta memorizzata in locale, mentre quella pubblica è inviata al server.

Al momento dell’autenticazione, il server genera una sfida (“challenge”) casuale che il dispositivo firma con la chiave privata. Prima di farlo, il dispositivo può richiedere uno sblocco locale, ad esempio tramite impronta digitale. La firma viene poi verificata dal server utilizzando la chiave pubblica.

Dispositivi come YubiKey implementano questo modello in modo hardware, ma lo stesso principio è oggi integrato anche negli smartphone. Il vantaggio principale è che non esistono segreti condivisi né codici riutilizzabili, e l’autenticazione è legata al dominio, rendendo inefficaci gli attacchi di phishing tradizionali.

Perché lo standard scelto per la 2FA cambia davvero la sicurezza

Alla fine, parlare genericamente di 2FA può essere fuorviante. Come abbiamo visto, dietro lo stesso termine si nascondono modelli completamente diversi:

• alcuni basati su segreti condivisi e sincronizzazione temporale;
• altri su codici generati e trasmessi;
• altri ancora su firme crittografiche e identità del dispositivo.

La scelta dello standard non è solo una decisione tecnica, ma incide direttamente su usabilità, complessità e resistenza agli attacchi. Ed è proprio nel modo in cui questi standard vengono integrati che si determina la reale efficacia della protezione.

Qual è il miglior approccio lato utente

Dal punto di vista dell’utente finale, la scelta del metodo di 2FA non dovrebbe essere guidata solo dalla comodità: non tutte le opzioni offerte da un servizio sono equivalenti, anche se spesso sono presentate allo stesso modo.

In generale, quando possibile, è preferibile orientarsi verso soluzioni basate su standard robusti e progettati per essere phishing-resistant. I metodi fondati su FIDO2/WebAuthn, promossi dalla FIDO Alliance, rappresentano oggi il livello più alto di sicurezza disponibile per l’utente medio: eliminano i codici OTP, non utilizzano segreti condivisi e soprattutto legano l’autenticazione al dominio, impedendo di fatto gli attacchi di tipo man-in-the-middle.

L’utilizzo di dispositivi dedicati come YubiKey o delle passkey consente di ottenere un’autenticazione forte senza aumentare la complessità operativa.

Quando queste soluzioni non sono disponibili, il compromesso migliore resta l’uso di applicazioni TOTP come Google Authenticator ma anche Proton Authenticator. Pur non essendo immuni al phishing, offrono un buon livello di sicurezza perché non dipendono da canali esterni e non espongono direttamente il segreto durante l’autenticazione. Diventa importante proteggere il dispositivo su cui sono installate e gestire con attenzione i codici di backup: ne abbiamo parlato anche nell’articolo su come evitare il blocco dell’account Google.

Le soluzioni basate su SMS o email dovrebbero essere considerate l’ultima opzione, da utilizzare solo quando non esistono alternative. Il loro limite non è tanto l’algoritmo, quanto l’infrastruttura: il controllo del numero telefonico o dell’account email può essere trasferito o compromesso senza che l’utente se ne accorga immediatamente.

Dove possibile, è consigliabile attivare più metodi in parallelo, privilegiando quelli più sicuri come principale e mantenendo gli altri solo come fallback controllato. In questo modo si riduce il rischio di lockout (ovvero il rischio di restare fuori dal proprio account) senza abbassare il livello complessivo di protezione.

Differenze tra 2FA e MFA

Nel linguaggio comune i termini 2FA e MFA (Multi-Factor Authentication) sono spesso usati come sinonimi, ma dal punto di vista tecnico la distinzione è rilevante.

L’autenticazione multifattoriale (MFA) è il concetto generale: richiede due o più fattori appartenenti a categorie diverse. La 2FA è semplicemente il caso più comune di MFA, in cui i fattori sono esattamente due. È una distinzione definita anche nelle linee guida del NIST (SP 800-63), che classificano i livelli di autenticazione proprio in base al numero e alla qualità dei fattori.

Oggi molti sistemi non si fermano più a due fattori. Alcuni esempi concreti:

• password + TOTP + verifica biometrica;
• passkey (che combinano dispositivo + biometria in un unico flusso);
• autenticazione adattiva con fattori dinamici (geolocalizzazione, comportamento, device fingerprint).

In questi casi, parlare di 2FA è riduttivo o addirittura impreciso. Il termine corretto è spesso MFA, perché: i fattori possono essere più di due; alcuni fattori non sono espliciti per l’utente; la verifica dell’identità può avvenire in modo continuo nel tempo (continuous authentication), cioè il sistema controlla costantemente che l’utente sia realmente chi dichiara di essere durante tutta la sessione, e non solo al momento dell’accesso.

Un errore frequente consiste nel confondere autenticazione in due passaggi con “due fattori”. Se torniamo all’esempio di prima, dell’autenticazione con password più codice OTP inviato via email sullo stesso dispositivo già compromesso, ci troviamo davanti a un’autenticazione in due passaggi che però non può essere considerata neppure 2FA perché i due fattori non sono realmente indipendenti. La sicurezza dipende dalla separazione dei fattori, non dal numero di “step”.

Quando la 2FA non basta: tecniche avanzate di bypass e compromissione

Nonostante la 2FA rappresenti un enorme passo avanti rispetto all’uso della sola password, molti attacchi moderni non cercano di rompere il secondo fattore, ma di aggirarlo, sfruttando debolezze nel flusso di autenticazione, nella gestione delle sessioni o nel comportamento dell’utente.

Phishing in tempo reale (Adversary-in-the-Middle)

È una delle tecniche oggi più efficaci in assoluto. Framework come Evilginx o Modlishka permettono di creare un proxy che si interpone tra l’utente e il servizio reale. Il flusso dell’attacco è il seguente:

• la vittima accede a un sito clone (identico all’originale e realizzato nell’ambito di una campagna phishing);
• inserisce username e password;
• il proxy inoltra i dati al server reale;
• quando viene richiesto l’OTP, la vittima lo inserisce;
• il proxy lo intercetta e gli aggressori lo usano immediatamente.

Il punto critico è che l’attaccante non “rompe” la 2FA ma la utilizza in tempo reale traendo in inganno l’utente. In molti casi, oltre alle credenziali, sono catturati anche i cookie di sessione, permettendo l’accesso persistente senza ulteriori verifiche. Ne ha parlato di recente Microsoft registrando un’intensificazione degli attacchi anche lato business ed enterprise; ne abbiamo parlato con la truffa dei Dispositivi collegati su WhatsApp (l’approccio è simile perché l’aggressore si pone tra l’utente e i server WhatsApp).

Furto di sessione (session hijacking)

Una volta completata l’autenticazione, molti sistemi si basano su cookie o token di sessione. Se questi vengono sottratti non è necessario ripetere la 2FA e l’attaccante può impersonare l’utente senza ulteriori passaggi.

Questo tipo di attacco si presenta spesso in combinazione con phishing e malware. Il problema è amplificato quando la sessione non è legata a IP o dispositivo, non esistono controlli evoluti e i i token hanno lunga durata.

I cookie di sessione sono salvati direttamente nel browser dell’utente e vengono inviati automaticamente a ogni richiesta HTTP verso il dominio del servizio. I token (ad esempio JWT o simili), invece, possono essere salvati a loro volta nei cookie, nella memoria del browser (localStorage, sessionStorage) oppure gestiti da applicazioni mobili.

In entrambi i casi, rappresentano di fatto una “prova di autenticazione” già completata: chi possiede quel valore è considerato autenticato dal server.

MFA fatigue (push bombing)

Nei sistemi basati su notifiche push, l’attaccante sfrutta il fattore umano. Dopo aver in qualche modo ottenuto la password, l’aggressore invia ripetute richieste di autenticazione.

Ricevendo notifiche continue, per errore o frustrazione, è facile che la vittima ne approvi una consegnando così il suo account a un soggetto terzo.

L’attacco non richiede sofisticazione tecnica, ma è estremamente efficace. In molti casi è combinato con attività di ingegneria sociale (“sono dell’assistenza tecnica, approvi la richiesta, per favore“).

Malware e infostealer

I malware moderni sono progettati per aggirare anche la 2FA: intercettano codici OTP tramite keylogging o acquisizione di schermate sul dispositivo desktop o mobile, leggono notifiche sui dispositivi mobili, abusano dei permessi di accessibilità.

Nei casi più sofisticati, è possibile che venga sottratto il seed TOTP, ovvero la chiave segreta iniziale utilizzata per generare i codici temporanei di autenticazione a due fattori. In questo modo gli aggressori possono generare OTP autonomamente e bypassare completamente il secondo fattore. Abbiamo già visto, infatti, che disponendo del seed TOTP è possibile trasformare qualunque dispositivo in un authenticator.

Conclusioni

L’autenticazione a due fattori o 2FA e in generale la MFA rappresentano oggi uno dei pilastri della sicurezza digitale, ma non sono soluzioni uniformi né, tantomeno, definitive. Come abbiamo visto, sotto le etichette 2FA e MFA convivono modelli molto diversi tra loro: alcuni basati su segreti condivisi e codici temporanei, altri su canali di comunicazione esterni, altri ancora su crittografia asimmetrica e identità del dispositivo. Questa eterogeneità spiega perché non tutte le implementazioni offrano lo stesso livello di protezione.

Il punto centrale non è quindi “attivare la 2FA“, ma “quale 2FA si utilizza e com’è integrata nel sistema“. La sicurezza reale dipende dall’indipendenza dei fattori, dalla gestione delle sessioni, dalla robustezza dei flussi di ripristino e dalla capacità di resistere agli attacchi moderni, che sempre più spesso aggirano il secondo fattore invece di attaccarlo direttamente.

Allo stesso tempo, l’evoluzione verso modelli passwordless e standard come FIDO2/WebAuthn/passkey indica la via: è importante ridurre la dipendenza dalle credenziali statiche e dai codici riutilizzabili, puntando su meccanismi crittografici più solidi e meno esposti al phishing.