Che cos'è l'autenticazione a più fattori (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

Come funziona davvero TOTP

L’app di autenticazione, smitizzata – nessuna pagina di classifica spiega il macchinario (RFC 6238):

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 / 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 — 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();

// 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]])

// 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

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 pubblicano e che le spiegazioni dei fornitori non pubblicano – quali attacchi sconfiggono quali metodi:

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

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 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 – ereditata dall’identity provider, oppure imposta localmente per le azioni di alto valore.

Quale metodo MFA offrire? Matrice decisionale

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.