TOTP

TOTP (Time-based One-Time Password) è l’algoritmo alla base di Google Authenticator, Authy, la funzionalità TOTP di 1Password e della maggior parte dei 2FA basati su software. Definito in RFC 6238 (2011).

Come funziona: durante l’iscrizione, il server e l’app di autenticazione scambiano un segreto condiviso (tipicamente un valore a 160 bit codificato come stringa base32 o QR code). Per generare l’OTP corrente, entrambi i lati:

1. Prendono il tempo Unix corrente, diviso per il periodo (30 secondi per impostazione predefinita), arrotondato verso il basso.
2. Calcolano HMAC-SHA1 di quel contatore usando il segreto condiviso.
3. Troncano a 6 cifre.

Entrambi i lati producono lo stesso codice senza comunicare. La finestra di 30 secondi più una tolleranza di ±1 finestra gestisce la deriva dell’orologio. Il segreto condiviso non lascia mai il dispositivo dopo l’iscrizione.

TOTP è enormemente migliore dell’OTP via SMS (nessuna esposizione a SIM-swap) ma non sconfigge il phishing da solo — un attaccante che effettua il phishing del codice corrente può riprodurlo entro la finestra. WebAuthn / passkey sono la risposta di prossima generazione.

Il formato di provisioning del segreto condiviso: i QR code mostrati da Google Authenticator, GitHub, AWS IAM e altri codificano un URI otpauth://totp/Issuer:label?secret=BASE32SECRET&algorithm=SHA1&digits=6&period=30. Lo schema è una convenzione Google del 2011 piuttosto che una specifica IETF formale, ma ogni app di autenticazione principale la supporta. Alcuni servizi (Microsoft, Steam) estendono le cifre a 7-8 o accorciano il periodo a 15 secondi per una maggiore entropia a costo di una finestra più stretta. Leggi il QR con un’app generica una volta per catturare il segreto, poi conservalo offline — perdere l’accesso all’autenticatore senza quel backup significa passare attraverso il recupero dell’account.

SHA-1 in una specifica del 2026 — è sicuro? Sì, in questo contesto. L’uso di HMAC-SHA1 da parte di TOTP non è vulnerabile agli attacchi di collisione SHA-1 che hanno ritirato l’hash per i certificati TLS; HMAC dipende dalla resistenza alla preimmagine di SHA-1, che rimane intatta. RFC 6238 consente anche SHA-256 e SHA-512, ma praticamente ogni app di autenticazione usa SHA-1 per impostazione predefinita per la compatibilità tra vendor. Se l’URI di provisioning specifica algorithm=SHA256, il verificatore e l’autenticatore devono entrambi supportarlo — molte app più vecchie si romperanno silenziosamente. Correlato: OTP, SHA-256, JWT.

Esempio pratico: derivare un codice

Segreto condiviso (base32) JBSWY3DPEHPK3PXP. Supponi che il tempo Unix corrente sia 1700000000. Contatore = floor(1700000000 / 30) = 56666666. Impacchetta il contatore come un intero big-endian a 8 byte, calcola HMAC-SHA1(segreto, contatore) producendo un digest a 20 byte, prendi il nibble di ordine inferiore dell’ultimo byte come offset o, leggi 4 byte a partire da o, maschera il bit alto e applica il modulo di 10⁶. Il risultato è un codice a 6 cifre come 359152. A t = 1700000030 il contatore avanza di 1 e il codice ruota. Dodici secondi di sfasamento dell’orologio tra server e telefono sono innocui; sessanta secondi di solito falliscono la verifica a meno che il server non ampli la finestra di tolleranza.

Quando TOTP è la scelta giusta

TOTP ha senso come secondo fattore ovunque un attaccante che già possiede la password debba comunque essere bloccato: accessi bancari, hosting di codice, console cloud, email. Non sostituisce una password (il segreto è simmetrico — la compromissione del server rivela il seed di ogni utente) e non ferma i kit di phishing in tempo reale come evilginx che fa da proxy al flusso di login. Per l’autenticazione resistente al phishing, preferisci WebAuthn / passkey, che legano crittograficamente la credenziale all’origine legittima. Riferimento: NIST SP 800-63B — Digital Identity Guidelines (Authentication), che categorizza TOTP come un autenticatore AAL2 “qualcosa che hai” equivalente a un segreto memorizzato.