Come aggiungere l'autenticazione a due fattori TOTP e le policy di accesso condizionale alle applicazioni interne dell'azienda

Per aggiungere il 2FA TOTP e l'accesso condizionale alle applicazioni interne non si tocca il codice di ogni applicazione: si delega il login a un provider di identità via OpenID Connect e si configura il secondo fattore una volta, nel punto in cui l'autenticazione avviene. Le policy — 2FA disabilitata, opzionale o obbligatoria, durata della sessione, soglia di tentativi falliti, domini email ammessi — si applicano poi per tenant, per progetto e per ruolo, così il pannello di amministrazione può richiedere il secondo fattore sempre mentre l'intranet lo lascia opzionale, con la stessa base utenti.

Cos'è il TOTP, in concreto

TOTP (Time-based One-Time Password, RFC 6238) è un'estensione di HOTP in cui il contatore è il tempo. Server e app di autenticazione condividono un segreto generato una sola volta, alla registrazione; a ogni login entrambi calcolano un HMAC sul segreto e sul numero di intervalli di 30 secondi trascorsi da un'epoca comune, e ne troncano il risultato a 6 cifre. Non transita nulla in rete oltre al codice, e il codice scade da solo.

otpauth://totp/Example:mario.rossi@example.com
  ?secret=JBSWY3DPEHPK3PXP
  &issuer=Example
  &algorithm=SHA1
  &digits=6
  &period=30

Il TOTP funziona offline, non dipende dalla rete mobile e non ha il costo per messaggio degli SMS. Soprattutto, non è vulnerabile al SIM swap, che è il motivo per cui il NIST considera da anni l'OTP via SMS un fattore debole. Resta invece esposto al phishing in tempo reale: chi si fa consegnare il codice su una pagina clone lo riusa entro i 30 secondi. Per le applicazioni più sensibili, il passaggio successivo sono i fattori legati all'origine crittografica, trattati su autenticazione passwordless.

Passo 1 — Classifica le applicazioni interne

L'errore che fa fallire i progetti MFA non è tecnico: è imporre il secondo fattore ovunque nello stesso giorno. La classificazione serve a decidere dove il costo di frizione è giustificato.

Passo 2 — Centralizza il login, non il secondo fattore

Se ogni applicazione implementa il proprio TOTP, ottieni N segreti per utente, N flussi di recupero e N implementazioni da mantenere aggiornate. Delegando il login via OIDC, il secondo fattore vive nel provider di identità: l'applicazione riceve un token e non sa nemmeno se l'utente ha usato una password, un codice TOTP o un SSO aziendale.

import { LoginMaster } from "@loginmaster/sdk";

const lm = new LoginMaster({
  projectKey: process.env.LOGINMASTER_PROJECT_KEY,
  tenant: "https://tenant.example.com",
});

const session = await lm.verifyToken(token);
if (session.valid) {
  // La policy 2FA del progetto è già stata applicata a monte
  const userId = session.subject;
}

Chi non usa TypeScript o .NET fa lo stesso via REST con POST /v1/auth/verify. Il dettaglio degli SDK è su Integrazione. Se le applicazioni interne sono già federate con Entra ID o Google Workspace, la guida al SSO è qui.

Passo 3 — Attiva il TOTP con parametri sensati

• Genera il segreto lato server con un generatore crittograficamente sicuro, almeno 160 bit, e mostralo all'utente una sola volta.
• Conferma l'attivazione solo dopo che l'utente ha inserito un codice valido: senza questa verifica, un utente che ha inquadrato male il QR resta chiuso fuori.
• Rifiuta il riuso di un codice già consumato nella stessa finestra: senza questo controllo il replay di 30 secondi è banale.
• Applica un limite di tentativi per utente e per indirizzo IP: 6 cifre sono un milione di combinazioni, un attacco automatizzato senza limiti le prova in fretta.
• Tieni la tolleranza di deriva a ±1 intervallo. Alzarla a ±5 per 'ridurre i ticket' allunga la finestra utile di un codice rubato da 90 secondi a cinque minuti.

Passo 4 — Enrollment e recupero: la parte che si sottovaluta

Il 2FA introduce un problema nuovo: cosa succede a chi perde il telefono. La risposta scelta qui determina il livello di sicurezza reale del sistema, molto più dei parametri crittografici.

La scorciatoia diffusa è dare all'helpdesk la facoltà di disattivare il secondo fattore su richiesta. È comodo, ed è anche il punto in cui l'intero investimento in MFA si annulla: da quel momento la sicurezza dell'account dipende dalla capacità di un operatore di riconoscere una telefonata di ingegneria sociale. Gli incidenti più noti degli ultimi anni sono passati esattamente da lì, non da una debolezza dell'algoritmo.

1. 1Alla registrazione consegna codici di recupero monouso e chiedi conferma esplicita che siano stati salvati.
2. 2Consenti la registrazione di più dispositivi: è la contromisura più efficace, perché evita il recupero nella maggior parte dei casi.
3. 3Definisci per iscritto la procedura di recupero e i canali verificati che usa (email registrata, numero di telefono confermato).
4. 4Dichiara i tempi di recupero nella documentazione interna: una procedura sicura che nessuno conosce diventa un ticket urgente il primo lunedì mattina.
5. 5Registra ogni recupero come evento di sicurezza e invialo al SIEM: è uno degli eventi più interessanti da correlare.

Passo 5 — Le policy di accesso condizionale

"Accesso condizionale" significa che la decisione di autenticazione dipende dal contesto invece di essere una costante. Vale la pena essere precisi su cosa fa una piattaforma, perché il termine copre due famiglie diverse: le policy dichiarate — chi accede a cosa, con quale fattore e per quanto tempo — e la valutazione del rischio basata su segnali comportamentali e machine learning.

LoginMaster implementa la prima famiglia: condizioni deterministiche, verificabili e documentabili in un audit, dichiarate a livello di tenant, progetto e ruolo. È una scelta esplicita, ed è anche la famiglia che copre la maggior parte dei requisiti reali di un'organizzazione che deve mettere in sicurezza le proprie applicazioni interne.

Un esempio di matrice applicata

Passo 6 — Il rollout che non genera rivolte

1. 1Settimana 1: attiva la 2FA obbligatoria sui ruoli amministrativi. Sono pochi, sono i più esposti e sono i più motivati.
2. 2Settimane 2-4: rendi il 2FA opzionale per tutti, con una comunicazione che spiega il perché e una guida di enrollment di una pagina.
3. 3Settimana 5: rendilo obbligatorio per i ruoli con accesso a dati personali o finanziari, comunicando la data con almeno due settimane di anticipo.
4. 4Settimana 6+: estendi progressivamente per reparto, monitorando la percentuale di enrollment e il volume di ticket.
5. 5Sempre: misura. Enrollment completati, recuperi richiesti, login falliti per codice errato. Se i recuperi esplodono, il problema è la comunicazione, non il TOTP.

Passo 7 — Scenari limite da collaudare

• Orologio del telefono disallineato di 2 minuti: il codice deve essere rifiutato con un messaggio che suggerisce la sincronizzazione dell'ora.
• Stesso codice inviato due volte: il secondo tentativo deve fallire.
• Tentativi ripetuti con codici casuali: deve scattare il blocco temporaneo e generare un evento di sicurezza.
• Enrollment interrotto a metà: l'utente deve poter ricominciare senza restare in uno stato intermedio bloccante.
• Dispositivo smarrito con codici di recupero disponibili: rientro autonomo, senza intervento dell'helpdesk.
• Utente federato via SSO con MFA già applicata dall'IdP: nessuna doppia richiesta di secondo fattore.
• Ogni evento sopra deve comparire nel log di autenticazione e arrivare al SIEM.

L'ultimo punto non è un dettaglio di completezza: gli eventi di attivazione, disattivazione tentata e recupero del secondo fattore sono fra le prove richieste per i controlli ISO 27001 sugli accessi. Il dettaglio degli eventi e dei formati di export è su integrazione SIEM.

Confronto: cosa chiedere a una piattaforma

Le piattaforme di autenticazione offrono quasi tutte il TOTP. Le differenze che contano emergono sulle domande che nessuno fa in fase di selezione, e che diventano rilevanti dopo il primo incidente.

Il confronto esteso con le singole piattaforme è nell'hub delle alternative; le funzionalità MFA disponibili sono descritte su MFA adattiva e autenticazione adattiva.

Chi ha scritto questa guida

LoginMaster è la piattaforma IAM di CDBKR S.r.l., azienda italiana che progetta e gestisce infrastruttura di autenticazione per software house, MSP e organizzazioni enterprise europee. Il criterio applicato qui — nessun amministratore può intervenire sulle credenziali o sul secondo fattore di un utente — è lo stesso vincolo architetturale su cui è costruito il prodotto, descritto su Sicurezza e autenticazione zero-knowledge. Per una valutazione sul proprio scenario: contatti.