---
term: 'Autenticazione a più fattori (MFA)'
seoTitle: 'Autenticazione a più fattori (MFA): metodi, TOTP, passkey'
headline: 'Che cos''è l''autenticazione a più fattori (MFA)?'
slug: autenticazione-multifattore-mfa
category: auth-security
shortDefinition: 'L''autenticazione a più fattori è un controllo di accesso che richiede due o più tipi diversi di prova: qualcosa che si sa, si ha o si è.'
relatedTerms:
  - passwordless-authentication
  - oauth-2-social-login
  - identity-access-management-iam
  - json-web-token-jwt
contrastsWith:
  - passwordless-authentication
aboutTerms:
  - 'TOTP'
  - 'Phishing-Resistant MFA'
  - 'Passkeys'
  - 'MFA Fatigue'
faq:
  - question: 'Che cos''è la MFA, in parole semplici?'
    answer: 'Un accesso che richiede due o più tipi diversi di prova – per esempio una password più un codice dal telefono – così che una password rubata, da sola, non apra nulla. Le prove devono venire da categorie diverse: una password più una domanda di sicurezza resta un solo fattore, ripetuto due volte.'
  - question: 'Qual è la differenza tra MFA e 2FA?'
    answer: 'La portata. 2FA significa esattamente due fattori; MFA significa due o più. Ogni 2FA è una MFA, e in pratica la maggior parte delle installazioni MFA è una 2FA. Il numero conta meno della qualità: due fattori resistenti al phishing battono tre fattori attaccabili.'
  - question: 'Quali sono i tre fattori dell''autenticazione?'
    answer: 'Qualcosa che si sa (password, PIN), qualcosa che si ha (telefono, chiave hardware), qualcosa che si è (impronta, volto). Posizione e comportamento compaiono come segnali supplementari, ma alimentano controlli adattivi basati sul rischio invece di valere come fattori a sé stanti.'
  - question: 'L''autenticazione a due fattori via SMS è sicura?'
    answer: 'Meglio di una password da sola, ma è il metodo diffuso più debole: SIM swapping, intercettazione dei protocolli di telefonia e normale phishing lo sconfiggono tutti. Gli enti di standardizzazione lo limitano da anni, e le attuali indicazioni governative sono nette: non usare gli SMS come secondo fattore dove è disponibile qualcosa di più robusto.'
  - question: 'Come funziona un''app di autenticazione TOTP?'
    answer: 'Alla registrazione il codice QR consegna all''app un segreto condiviso. Da quel momento app e server calcolano in modo indipendente un codice a partire da quel segreto e dalla finestra temporale corrente di 30 secondi; codici uguali provano il possesso. Tutto offline: nessuna rete, nessun account presso chi ha scritto l''app, solo orologi sincronizzati e matematica.'
  - question: 'Le passkey sostituiscono la MFA?'
    answer: 'Per la maggior parte degli account, in pratica sì: una passkey è a più fattori in un solo gesto – il possesso del dispositivo più la biometria o il PIN che lo sblocca – e inoltre resistente al phishing, perché la firma funziona solo sul sito autentico. I contesti ad alta garanzia possono comunque sovrapporre un fattore separato.'
  - question: 'Che cos''è la MFA resistente al phishing?'
    answer: 'Una MFA che non può essere inoltrata attraverso un sito falso. Codici e approvazioni push si possono far passare da un proxy in tempo reale; i metodi a chiave pubblica – passkey e chiavi di sicurezza hardware sotto WebAuthn – legano la risposta in modo crittografico al dominio reale, così un sito sosia ottiene una firma che altrove non vale nulla.'
  - question: 'Che cos''è un attacco di stanchezza da MFA?'
    answer: 'Il push bombing: chi attacca, con una password rubata, scatena richieste di approvazione fino a quando la vittima sfinita non tocca "sì" – il metodo dietro diverse violazioni celebri. Le mitigazioni, in ordine: corrispondenza numerica nelle richieste, limiti di frequenza sui tentativi e, in ultima analisi, il passaggio a metodi in cui non c''è nulla da approvare.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST SP 800-63B — Digital Identity Guidelines: Authentication'
    url: 'https://pages.nist.gov/800-63-4/sp800-63b.html'
  - name: 'RFC 6238 — TOTP: Time-Based One-Time Password Algorithm'
    url: 'https://datatracker.ietf.org/doc/html/rfc6238'
  - name: 'CISA — Implementing Phishing-Resistant MFA'
    url: 'https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf'
  - name: 'W3C Web Authentication (WebAuthn)'
    url: 'https://www.w3.org/TR/webauthn-3/'
  - name: 'Multi-factor authentication — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Multi-factor_authentication'
cta:
  title: 'Autenticazione step-up senza costruirla'
  text: 'L''adattatore MFA di Back4app aggiunge il TOTP al tuo flusso di accesso con un blocco di configurazione: registrazione, finestre di verifica e codici di recupero gestiti dalla piattaforma, sopra sessioni che può revocare all''istante.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-06'
translationKey: multi-factor-authentication-mfa
---

**L'autenticazione a più fattori è un controllo di accesso che richiede due o più tipi diversi di prova: qualcosa che si sa, si ha o si è.** La parola *diversi* porta tutto il peso ed è largamente maneggiata male: una password più una domanda di sicurezza sono due prove di una sola categoria – la conoscenza – e quindi non sono affatto MFA. Il punto è combinatorio: una password sottratta con il phishing non tiene in mano il telefono; un telefono rubato non conosce il PIN; il furto di ciascun fattore lascia chi attacca a corto di una categoria.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| I fattori | Sapere (password) · avere (dispositivo, chiave) · essere (biometria) – da categorie *diverse* |
| MFA vs. 2FA | 2FA = esattamente due; MFA = due o più; la qualità batte la quantità |
| La classifica | SMS < TOTP < push < push + corrispondenza numerica < **passkey / chiavi di sicurezza** |
| La linea di demarcazione | Resistenza al phishing: i codici si possono inoltrare, la crittografia legata all'origine no |
| L'anello debole | Il recupero – i flussi di reimpostazione devono essere forti come l'accesso che scavalcano |

## Come funziona davvero TOTP

L'app di autenticazione, smitizzata – nessuna pagina di classifica spiega il macchinario ([RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238)):

```text
Registrazione  QR code = otpauth://totp/app:ada?secret=JBSWY3DP…
               → ora l'app condivide un SEGRETO Base32 con il server

Ogni 30 s      i due lati calcolano, in modo indipendente e offline:
               code = truncate( HMAC-SHA1( secret, floor(unix_time / 30) ) ) % 10⁶

Accesso        si digitano le 6 cifre dell'app; il server calcola le proprie,
               accetta ±1 finestra temporale per la deriva dell'orologio → uguale = possesso provato
```

Come si innesta tutto questo nel flusso di accesso di un'app:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
await currentUser.save({
  authData: { mfa: { secret: totpSecret, token: codeFromApp } },
});
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
const user = await Parse.User.logIn('ada', password, {
  authData: { mfa: { token: codeFromApp } },
});
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
currentUser.set('authData', {
  'mfa': {'secret': totpSecret, 'token': codeFromApp},
});
await currentUser.save();
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
final user = ParseUser('ada', password, null)
  ..set('authData', {'mfa': {'token': codeFromApp}});
await user.login();
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
let enrolled = try await currentUser.link("mfa",
    authData: ["secret": totpSecret, "token": codeFromApp])
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
let user = try await User.login("ada", password: password,
    authData: ["mfa": ["token": codeFromApp]])
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
val enroll = mapOf("secret" to totpSecret, "token" to codeFromApp)
ParseUser.getCurrentUser().linkWithInBackground("mfa", enroll)
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
val authData = mapOf("token" to codeFromApp)
ParseUser.logInWithInBackground("mfa", authData) // paired with the password check
```

## MFA vs. 2FA

| | 2FA | MFA |
| --- | --- | --- |
| Fattori | Esattamente due | Due o più |
| Relazione | Un sottoinsieme della MFA | Il termine ombrello |
| In pratica | Ciò che la maggior parte delle installazioni è davvero | Ciò con cui la maggior parte delle installazioni viene chiamata |

Una tabella chiude la questione; la domanda più acuta è *quali* fattori – perché il tetto di sicurezza non lo fissa quante prove si impilano, ma se qualcuna di esse possa essere sottratta con il phishing.

## La classifica dei metodi, onestamente

Il confronto che le [indicazioni della CISA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) pubblicano e che le spiegazioni dei fornitori non pubblicano – quali attacchi sconfiggono quali metodi:

| Metodo | Phishing / proxy in tempo reale | SIM swap | Push bombing | Offline? | Verdetto |
| --- | --- | --- | --- | --- | --- |
| Codici via SMS o voce | Sconfitto | **Sconfitto** | n/d | No | Ultima risorsa – [limitato dal NIST](https://pages.nist.gov/800-63-4/sp800-63b.html) |
| Codici via e-mail | Sconfitto | Al sicuro | n/d | No | Eredita la sicurezza della casella di posta |
| App TOTP | Sconfitto | Al sicuro | n/d | **Sì** | La base solida |
| Approvazione push | Sconfitto | Al sicuro | **Sconfitto** | No | Comodo, bombardabile |
| Push + corrispondenza numerica | Sconfitto | Al sicuro | Resistente | No | Comodità rattoppata |
| **Passkey / chiavi di sicurezza** | **Resistente** | Al sicuro | n/d | Sì | Lo standard d'oro ([WebAuthn](https://www.w3.org/TR/webauthn-3/)) |

Lo schema nella colonna più a sinistra è la storia moderna: *ogni* codice e ogni approvazione si possono inoltrare attraverso un proxy di phishing; solo la crittografia legata all'origine sopravvive al contatto con una pagina di accesso falsa.

## Gli attacchi, in parole chiare

```mermaid
flowchart LR
  accTitle: Proxy di phishing adversary-in-the-middle che inoltra la MFA
  accDescr: La vittima inserisce credenziali e un codice monouso su un sito falso, che li inoltra in tempo reale al sito autentico, riceve una sessione valida e consegna a chi attacca il cookie di sessione. Le passkey sconfiggono questo attacco perché la loro firma è legata al dominio autentico e fallisce su quello falso.
  V["Vittima"] -->|"password + codice OTP"| F["Pagina di accesso falsa<br/>(kit proxy)"]
  F -->|"inoltra in tempo reale"| R["Sito reale"]
  R -->|"cookie di sessione valido"| F
  F -->|"sessione consegnata"| A["Chi attacca è dentro"]
  P["Tentativo con passkey sulla pagina falsa"] -.->|"firma legata al dominio reale<br/>→ inutile per il proxy"| X["Fallisce"]
```

**Phishing adversary-in-the-middle:** kit proxy open source si mettono fra la vittima e il sito reale, inoltrando in diretta la password *e* il codice monouso, poi si tengono il cookie di sessione risultante – MFA "superata", account perso. **Push bombing:** con una password rubata, si inondano di richieste di approvazione fino a quando la stanchezza non ne fa passare una; la corrispondenza numerica (digitare le cifre mostrate sullo schermo) elimina la scorciatoia dell'approvazione distratta. **SIM swapping:** convincere un operatore a spostare il numero della vittima, e poi ricevere i suoi codici via SMS – l'attacco che ha messo gli SMS in fondo alla tabella. Il filo comune: questi sconfiggono i *fattori che si possono raccontare a qualcuno*; si infrangono tutti contro fattori che parlano solo in modo crittografico all'origine autentica.

## Il problema del recupero

Ogni adozione della MFA crea una seconda porta: che cosa succede quando il telefono si perde? I codici di recupero – monouso, generati alla registrazione, conservati offline – sono la risposta standard; i flussi di recupero dell'account sono quella pericolosa. Se una telefonata all'help desk o una reimpostazione via e-mail possono rimuovere la MFA, chi attacca telefona all'help desk – la tecnica dietro violazioni da prima pagina – e il controllo più forte viene scavalcato dal processo più debole. La regola: **il recupero deve esigere una garanzia pari o superiore all'accesso che sostituisce** – metodi registrati multipli, verifica step-up per le reimpostazioni e rimozione della MFA trattata come evento privilegiato, registrato e capace di far scattare un allarme.

## Quanto è efficace davvero la MFA?

Due affermazioni vere, spesso confuse. Contro gli attacchi *automatici* – credential stuffing, password spraying – la MFA è quasi totale: le celebri cifre del novantanove per cento vengono dalla telemetria degli accessi su larga scala che misura esattamente quelli, e uno studio di approfondimento sottoposto a revisione tra pari ha trovato una riduzione delle compromissioni intorno al 99 % nello stesso ambito. Contro il phishing *mirato* con proxy in tempo reale, la MFA basata su codici e su push è dimostrabilmente aggirabile, ed è per questo che i critici collocano molto più in basso l'efficacia su tutti gli attacchi e che le agenzie spingono ora in modo specifico sui metodi resistenti al phishing. La sintesi onesta: una qualsiasi MFA chiude l'epoca in cui la password bastava; solo la MFA di classe passkey chiude il phishing. Conviene installare *una qualche* MFA dappertutto, e la MFA resistente al phishing dove la posta in gioco giustifica l'attrito della registrazione.

## Casi d'uso tipici

- **Protezione dell'emissione degli account** – la MFA presidia il momento in cui [sessioni e token](/glossary/it/json-web-token-jwt/) vengono coniati; tutto quello che sta a valle si fida di quella barriera.
- **Step-up per le azioni sensibili** – richiesta ripetuta al pagamento, all'eliminazione o all'esportazione delle chiavi, non solo all'accesso.
- **Account di amministrazione e privilegiati** – dove la MFA dovrebbe essere obbligatoria e resistente al phishing, senza eccezioni.
- **Regimi di conformità** – i quadri normativi su pagamenti, sanità e settore pubblico richiedono sempre più la MFA in modo esplicito.
- **Complemento al [login social](/glossary/it/oauth-2-login-social/)** – ereditata dall'identity provider, oppure imposta localmente per le azioni di alto valore.

## Quale metodo MFA offrire? Matrice decisionale

| Situazione | Offrire |
| --- | --- |
| Base utenti generica, dispositivi vari | TOTP come base + passkey come percorso promosso |
| Account di alto valore o di amministrazione | Solo metodi resistenti al phishing – passkey o chiavi di sicurezza |
| Utenti senza smartphone | Chiavi hardware o codici di recupero stampati, non SMS per impostazione predefinita |
| Popolazione legacy, nessun'altra opzione praticabile | SMS – a occhi aperti, come pavimento e non come norma |
| Azioni sensibili dentro l'app | Riautenticazione step-up, qualunque sia il fattore di accesso |
| Progetto del recupero | Minimo due metodi registrati + codici offline |

## Limiti e trade-off

- **L'attrito è reale e misurabile.** Ogni richiesta costa conversioni e ticket di supporto; una richiesta adattiva, basata sul rischio, spende l'attrito dove il rischio abita.
- **Una MFA attaccabile con il phishing rende meno di quanto sembri.** Contro un attacco proxy mirato codici e push cadono: vanno trattati come fermamacchine per l'automazione, non come corazza anti-phishing.
- **Il telefono è un single point of failure.** La perdita del dispositivo senza un piano di recupero diventa blocco su larga scala – la UX di registrazione deve piantare i metodi di riserva già il primo giorno.
- **I flussi di recupero ribaltano i conti.** Un percorso di reimpostazione debole limita in silenzio l'intero schema alla propria robustezza.
- **La registrazione è il salto nel vuoto dell'adozione.** Gli obblighi senza flussi QR scorrevoli e alternative chiare generano resistenza; lo schema migliore è quello che le persone portano davvero a termine.

## La MFA su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il TOTP arriva come configurazione, non come costruzione: l'adattatore di autenticazione `mfa` di Back4app accende i codici a tempo con un blocco di configurazione – cifre, periodo e algoritmo regolabili – e le schede di codice mostrano l'intera storia lato client: la registrazione prova il possesso abbinando il segreto condiviso a un codice valido, il server emette codici di recupero monouso, e gli accessi successivi abbinano la password alle sei cifre correnti. Poiché le sessioni della piattaforma sono revocabili lato server, tiene anche l'igiene attorno: un cambio di MFA può terminare immediatamente le altre sessioni, e i trigger di Cloud Code sono il posto naturale in cui registrare gli eventi di registrazione e mettere la rimozione della MFA dietro controlli step-up – la disciplina del recupero per cui questo articolo argomenta, espressa in poche funzioni.