MFA e Authentication Factors

Mappa Globale — MFA e Authentication Factors
#

I Tre Fattori di Autenticazione
#

L'autenticazione multifattore si basa sul principio che verificare l'identita' da angolazioni diverse riduce drasticamente il rischio di compromissione. I fattori sono classificati in tre categorie fondamentali, e per parlare di MFA devono essere coinvolti almeno due categorie diverse.

flowchart LR
    subgraph KNOW["Type 1 - Something you KNOW"]
        K1["Password"]
        K2["PIN"]
        K3["Passphrase"]
        K4["Security Question"]
    end

    subgraph HAVE["Type 2 - Something you HAVE"]
        H1["Smart Card"]
        H2["Hardware Token\n(YubiKey)"]
        H3["Authenticator App\n(TOTP)"]
        H4["SMS OTP"]
    end

    subgraph ARE["Type 3 - Something you ARE"]
        A1["Fingerprint"]
        A2["Iris Scan"]
        A3["Face Recognition"]
        A4["Behavioral\n(keystroke dynamics)"]
    end

    MFA["MFA\n= 2+ fattori\ndi tipo DIVERSO"] --> KNOW
    MFA --> HAVE
    MFA --> ARE

Type 1 - Something you KNOW: La categoria piu' antica e piu' attaccata. Tutte le informazioni conosciute: password, PIN, passphrase, domande di sicurezza. Il problema principale non e' la debolezza intrinseca ma il comportamento umano: password riutilizzate, troppo corte, condivise. Una password lunga e unica rimane valida se gestita correttamente.

Type 2 - Something you HAVE: Oggetti fisici in tuo possesso. La differenza rispetto ai fattori know e' che richiedono la presenza fisica (o il furto fisico del dispositivo). Gli authenticator app moderni come Authy e Microsoft Authenticator rientrano in questa categoria.

Type 3 - Something you ARE: Caratteristiche biometriche. Il vantaggio e' che non si perdono e non si dimenticano; lo svantaggio e' che non si possono cambiare se vengono compromesse (non puoi reimpostare il tuo fingerprint come faresti con una password).

Errore critico da riconoscere: password + PIN non e' MFA. Sono entrambi fattori "something you know". Per essere MFA servono categorie diverse: know + have (password + TOTP), know + are (password + fingerprint), have + are (smart card + fingerprint).

Mappa — Quando ogni fattore fallisce
#

SMS OTP vs TOTP vs Hardware Token
#

I tre metodi principali per il fattore "something you have" hanno profili di sicurezza molto diversi. La scelta dipende dal contesto, ma la direzione generale del settore va chiaramente verso FIDO2.

flowchart TD
    subgraph SMS_F["SMS OTP"]
        S1["Server genera OTP"] --> S2["Invia via SMS (SS7)"] --> S3["Utente legge e inserisce"]
        S4["Vulnerabilita': SIM swap, SS7 intercept, phishing real-time"]
    end

    subgraph TOTP_F["TOTP (RFC 6238)"]
        T1["Seed condiviso\n(QR code setup)"] --> T2["HMAC-SHA1\n(seed + timestamp/30s)"] --> T3["6 cifre ogni 30s"]
        T4["Offline, no rete. Vulnerabile a phishing real-time (relay istantaneo)"]
    end

    subgraph FIDO_F["FIDO2 / Hardware Token"]
        F1["Browser invia\nchallenge + origin"] --> F2["Device verifica\norigine == dominio registrato"] --> F3["Firma con chiave privata"] --> F4["Server verifica firma"]
        F5["Immune a phishing: se origin != attesa, rifiuta"]
    end

    SMS_F ~~~ TOTP_F ~~~ FIDO_F

SMS OTP: Semplice da implementare e capillare (basta un numero di telefono), ma il canale SMS e' intrinsecamente insicuro. Il SIM swapping -- convincere l'operatore a trasferire il numero su una SIM dell'attaccante -- e' tecnicamente banale con un po' di social engineering. Gli attacchi SS7 permettono l'intercettazione diretta. NIST 800-63B lo ha declassato come metodo MFA standalone.

TOTP (Time-based One-Time Password): Generato offline dalla app (Google Authenticator, Authy, Microsoft Authenticator) usando HMAC-SHA1 applicato al seed segreto + il timestamp corrente diviso per 30 secondi (RFC 6238). Nessuna comunicazione di rete durante la generazione. Il punto debole e' la natura manuale: un attaccante che controlla una pagina phishing puo' ricevere le credenziali e il codice TOTP in tempo reale e rilayarli al sito legittimo prima che scadano.

Hardware Token FIDO2 (YubiKey, Google Titan): Risolve il problema del phishing in modo strutturale. Il device non risponde mai con la firma se l'origin della richiesta non corrisponde al dominio registrato durante il setup. Anche con una pagina phishing perfetta, l'attacco fallisce perche' il browser passa l'origin reale al device, che riconosce la discrepanza e rifiuta.

FIDO2 / WebAuthn
#

FIDO2 e' lo standard W3C + FIDO Alliance per l'autenticazione senza password. Usa crittografia asimmetrica: la chiave privata rimane nel device (o nel TPM/Secure Enclave), il server conosce solo la chiave pubblica. Non c'e' nessuna password da rubare da un database.

sequenceDiagram
    participant U as Utente
    participant B as Browser
    participant D as Device/TPM
    participant S as Server

    Note over U,S: REGISTRAZIONE
    S->>B: Challenge + dominio
    B->>D: Genera keypair per questo dominio
    D->>D: Salva private key internamente
    D->>B: Public key + attestation
    B->>S: Public key
    S->>S: Salva public key per l'utente

    Note over U,S: AUTENTICAZIONE
    S->>B: Challenge + origin
    B->>D: Richiesta firma
    D->>D: Verifica origin == dominio registrato
    D->>U: Chiede conferma (PIN/biometrica)
    U->>D: Conferma
    D->>B: Firma del challenge
    B->>S: Firma
    S->>S: Verifica firma con public key
    S->>B: Autenticato

Il meccanismo anti-phishing e' incorporato nel protocollo: il browser include sempre l'origin reale della pagina nella richiesta al device. Se stai su evil-bank.com invece di bank.com, il device vede l'origine sbagliata e rifiuta di firmare, indipendentemente da quanto convincente sia la pagina falsa.

Passkey e' l'implementazione consumer di FIDO2 da Apple, Google e Microsoft: la chiave privata e' sincronizzata in modo sicuro attraverso il cloud dell'ecosistema (iCloud Keychain, Google Password Manager), rendendo FIDO2 usabile anche quando si cambia device senza un token hardware fisico.

Dev parallel: FIDO2 e' strutturalmente simile a mTLS: invece di un certificato client, il browser presenta una firma crittografica derivata dalla chiave privata nel device. In entrambi i casi il server conosce solo la chiave pubblica e il segreto non transita mai sulla rete. Implementare WebAuthn in Node con @simplewebauthn/server o in PHP con web-auth/webauthn-framework.

Mappa — FIDO2 Components
#

Biometrics e Metriche di Qualita'
#

I sistemi biometrici sono valutati attraverso metriche specifiche che descrivono il tradeoff tra sicurezza e usabilita'. Queste metriche sono fondamentali per confrontare sistemi diversi e scegliere la soglia operativa corretta.

flowchart LR
    subgraph METRICS["Metriche Biometriche"]
        direction TB
        FAR["FAR - False Acceptance Rate\n% impostori accettati\n(errori di sicurezza)"]
        FRR["FRR - False Rejection Rate\n% legittimi rifiutati\n(errori di usabilita')"]
        CER["CER / EER\nCrossover Error Rate\nPunto dove FAR = FRR\n(benchmark qualita')"]
    end

    subgraph TRADEOFF["Il Tradeoff"]
        LOW["Soglia bassa\n(sistema permissivo)\nFAR alto\nFRR basso"]
        HIGH["Soglia alta\n(sistema restrittivo)\nFAR basso\nFRR alto"]
        OPT["Soglia ottimale\n= CER/EER\nEquilibrio sicurezza/usabilita'"]
    end

    METRICS --> TRADEOFF

FAR (False Acceptance Rate): La percentuale di volte che il sistema accetta un impostore come se fosse un utente legittimo. Un FAR basso significa che il sistema e' difficile da ingannare dall'esterno, ma non dice nulla su quanto sia frustrante per gli utenti legittimi.

FRR (False Rejection Rate): La percentuale di volte che il sistema rifiuta un utente legittimo. Un FRR alto significa utenti frustrati che si trovano bloccati dal sistema che dovrebbe riconoscerli. In ambienti ad alto throughput (tornelli aeroportuali) un FRR anche dell'1% e' inaccettabile.

CER / EER (Crossover Error Rate / Equal Error Rate): Il punto sulla curva dove FAR e FRR si equivalgono. E' il benchmark standard per confrontare sistemi biometrici diversi: un sistema con CER 1% e' piu' accurato di uno con CER 5%, indipendentemente dalla soglia specifica scelta per l'operativita'.

Il tradeoff e' ineliminabile: abbassare la soglia di accettazione riduce i falsi rifiuti (FRR cala) ma aumenta le false accettazioni (FAR sale). Alzarla fa l'opposto. La soglia operativa ottimale dipende dal contesto: per un sistema high-security si preferisce FAR basso anche a costo di FRR alto; per un sistema consumer si privilegia la comodita'.

Mappa — Biometrics in Pratica
#

Passwordless
#

Passwordless non significa autenticazione piu' debole: significa eliminare il vettore di attacco piu' sfruttato (credenziali rubate da breach o phishing) usando meccanismi crittograficamente piu' solidi.

I principali approcci passwordless in uso enterprise:

FIDO2 / Passkey: chiave asimmetrica nel device, resistente al phishing per design
Certificate-Based Authentication (CBA): smart card o certificato client in un file sicuro; Entra ID CBA lo supporta nativamente per Microsoft 365
Magic Link: link monouso via email (richiede sicurezza della casella email)
Windows Hello for Business: combina PIN locale + TPM per autenticazione senza password verso Active Directory / Entra ID

Dev parallel: In Symfony, l'autenticazione passwordless via magic link si implementa con un token temporaneo nel database (30 minuti di validita', monouso) e redirect con query string firmata. Simile alla logica password reset, ma usato come metodo di autenticazione principale. symfony/security-bundle supporta custom authenticators per questo pattern.

MFA Fatigue e Contromisure
#

MFA Fatigue (detto anche Prompt Bombing) e' una tecnica di social engineering in cui l'attaccante, dopo aver rubato username e password, genera push notification MFA ripetutamente sperando che l'utente approvi per errore o frustrazione. E' stato usato in attacchi reali contro Uber (2022) e Cisco.

sequenceDiagram
    participant A as Attaccante
    participant IDP as Identity Provider
    participant U as Utente Target

    A->>IDP: Login con credenziali rubate
    IDP->>U: Push MFA notification #1
    A->>IDP: Login con credenziali rubate
    IDP->>U: Push MFA notification #2
    A->>IDP: Login con credenziali rubate
    IDP->>U: Push MFA notification #3
    Note over U: Frustrazione / errore
    U->>IDP: Approva (!)
    IDP->>A: Sessione autenticata

Contromisure:

Number Matching: al momento dell'approval, l'utente deve digitare un numero mostrato sullo schermo del login. L'attaccante non puo' conoscerlo per comunicarlo all'utente.
Additional Context: la push mostra il device, la posizione geografica e l'app che ha richiesto l'accesso. Un login da Mosca alle 3 di notte dovrebbe essere ovvio.
FIDO2: elimina il problema alla radice -- non ci sono push MFA da approvare.
Numero massimo di tentativi: blocco temporaneo dopo N richieste MFA fallite in un intervallo breve.

Mappa — MFA in Enterprise
#

SSO e MFA
#

In un'architettura enterprise, MFA non viene implementata su ogni singola applicazione: viene centralizzata sull'Identity Provider (IdP). L'utente esegue MFA una volta al giorno (o per sessione) verso l'IdP (Okta, Microsoft Entra ID, Google Workspace), che poi propaga l'autenticazione alle app via SAML 2.0 o OIDC.

Dev parallel: In Symfony con Entra ID come IdP via OIDC (knpuniversity/oauth2-client-bundle), l'applicazione non gestisce mai la password ne' l'MFA -- delega tutto all'IdP. La sessione Symfony viene creata sulla base del token OIDC ricevuto dopo che l'utente ha gia' completato MFA sull'IdP. La stessa logica vale per Laravel Socialite o Next.js con NextAuth.js.

Collegato a
#

identity-proofing -- verifica dell'identita' prima dell'emissione delle credenziali
sso-kerberos-saml -- SSO centralizza l'MFA sull'IdP, propaga via SAML/Kerberos
oauth-oidc -- OIDC porta MFA nell'ecosistema OAuth2/OIDC
aaa-radius -- RADIUS puo' applicare policy MFA per accesso VPN e 802.1X
zero-trust -- MFA ovunque e' un pilastro fondamentale di Zero Trust
account-lifecycle -- provisioning/deprovisioning include gestione credenziali MFA
pki -- certificate-based authentication come alternativa passwordless a MFA tradizionale
ssl-tls -- mTLS e' certificate-based auth a livello di trasporto

Mappa Globale — MFA e Authentication Factors#

I Tre Fattori di Autenticazione#

Mappa — Quando ogni fattore fallisce#

SMS OTP vs TOTP vs Hardware Token#

FIDO2 / WebAuthn#

Mappa — FIDO2 Components#

Biometrics e Metriche di Qualita'#

Mappa — Biometrics in Pratica#

Passwordless#

MFA Fatigue e Contromisure#

Mappa — MFA in Enterprise#

SSO e MFA#

Collegato a#

Related