Debugger di codici TOTP / 2FA

Cosa sono davvero le sei cifre

Un codice TOTP — il numero che un'app di autenticazione rinnova ogni trenta secondi — non è casuale né viene memorizzato da nessuna parte. Viene calcolato, sia sul tuo telefono sia sul server, da due cose che già condividono: un segreto impostato una volta quando hai attivato l'autenticazione a due fattori, e l'ora attuale. Poiché entrambi i lati possono calcolarlo in modo indipendente, nulla deve viaggiare tra loro all'accesso; il server esegue semplicemente lo stesso calcolo e verifica che la sua risposta corrisponda alla tua.

TOTP (RFC 6238) è un sottile strato sopra uno schema più vecchio, HOTP (RFC 4226). HOTP trasforma un segreto e un contatore in un codice; TOTP è semplicemente HOTP con il contatore impostato al numero di passi temporali dall'epoca Unix. È tutta qui l'idea: dividi l'ora Unix attuale per la lunghezza del passo (30 secondi per impostazione predefinita) e passa il risultato a HOTP. Questo strumento mostra ogni passo di quel calcolo, perché quando un codice non verifica, la risposta è quasi sempre visibile da qualche parte nella derivazione.

La derivazione, passo per passo

Cinque passi portano dal segreto e dall'ora alle cifre che digiti. Lo strumento stampa ciascuno così puoi confrontarlo con la tua implementazione:

• Il contatore. Prendi l'ora Unix in secondi, sottrai T0 (0 in ogni distribuzione reale), dividi per il periodo e arrotonda per difetto. Con passi di 30 secondi, ogni momento nello stesso mezzo minuto dà lo stesso contatore, ecco perché un codice dura quanto dura.
• L'HMAC. Scrivi il contatore come 8 byte big-endian e calcola HMAC(segreto, contatore) con l'hash scelto — SHA-1 per quasi tutte le app. Questo produce un digest di 20 byte per SHA-1 (32 per SHA-256, 64 per SHA-512).
• Lo scostamento. Prendi i quattro bit bassi dell'ultimo byte del digest. È un numero da 0 a 15 e dice dove leggere nel digest — troncamento dinamico, così lo stesso segreto non usa sempre gli stessi byte.
• Il valore a 31 bit. Leggi quattro byte a partire dallo scostamento e maschera il bit alto (per evitare confusioni di segno). Resta un intero a 31 bit.
• Il codice. Prendi quell'intero modulo 10^cifre e riempi con zeri a sinistra. Sei cifre è la scelta quasi universale; sette e otto esistono e sono ammesse.

Il mascheramento del bit alto e il modulo sono gli unici passi con perdita: molti digest diversi mappano alle stesse sei cifre, e va bene, perché il codice deve essere difficile da indovinare solo nei trenta secondi in cui vive, non unico per sempre.

Perché un codice non corrisponde — le tre cause abituali

Una mancata corrispondenza TOTP non arriva mai con un messaggio di errore; il codice è semplicemente sbagliato. In pratica è quasi sempre una di tre cose, e i pannelli qui sono disposti per distinguerle:

• Il segreto è stato letto nel formato sbagliato. Un segreto di autenticatore è Base32, ma gli stessi caratteri letti come hex — o un segreto che era in realtà hex letto come Base32 — producono byte completamente diversi e un codice completamente diverso. Cambia il selettore di formato e vedi quale dà il codice atteso.
• Un parametro differisce. Il valore predefinito schiacciante è HMAC-SHA-1, 6 cifre, un periodo di 30 secondi. Un server che usa SHA-256, o 8 cifre, o un passo di 60 secondi, sarà in disaccordo con un'app lasciata sui valori predefiniti. L'otpauth:// URI porta tutti e tre, per questo scansionare un QR li azzecca e digitare un segreto a mano spesso no.
• Gli orologi sono andati alla deriva. TOTP presume che entrambi i lati concordino sull'ora. Se l'orologio di un telefono va avanti di un minuto, il suo codice è un minuto avanti a quello del server. A questo serve la finestra di deriva: verificare un codice contro i passi ai due lati dell'adesso dice non solo se corrisponde ma di quanto l'orologio è sfasato.

RFC 6238 raccomanda una finestra di validazione di al massimo un passo per lato — abbastanza per assorbire lo sfasamento d'orologio ordinario e la corsa del momento di rinnovo, senza allargare lo spazio di ricerca più del necessario. Questo strumento usa ±1 per impostazione predefinita e ti lascia allargarla durante il debug.

Segreti, Base32 e l'otpauth:// URI

Il segreto è condiviso una volta, alla configurazione, e tutto il resto ne deriva. Le app di autenticazione lo codificano in Base32 (RFC 4648) — l'alfabeto A–Z e 2–7, che evita i caratteri facili da confondere e sopravvive alla stampa sotto un QR. Questo strumento legge Base32 per impostazione predefinita, ignorando gli spazi che le app aggiungono per leggibilità e le maiuscole, e accetta anche hex così puoi riprodurre i vettori di test di RFC 6238, i cui segreti sono dati come byte grezzi.

Nemmeno il codice QR che scansioni alla configurazione è magia: codifica un otpauth:// URI in testo semplice che porta il segreto e tutti i parametri. Incollane uno qui per riempire i campi, o costruiscine uno dai campi per spostare una configurazione tra app:

otpauth://totp/GitHub:[email protected]?secret=JBSWY3DPEHPK3PXP&issuer=GitHub&algorithm=SHA1&digits=6&period=30

Solo il tipo totp è accettato. Un otpauth://hotp URI porta un contatore invece di un periodo, e trattarlo come TOTP produrrebbe silenziosamente codici sbagliati — quindi è rifiutato invece di essere indovinato.

Algoritmo, cifre e periodo

RFC 6238 ammette HMAC-SHA-1, SHA-256 o SHA-512, da sei a otto cifre, e qualsiasi lunghezza di passo. In pratica il mondo si è assestato su SHA-1, sei cifre e trenta secondi, e la maggior parte delle app implementa solo quella combinazione — un server che sceglie altro deve sperare che l'app dell'utente segua, e molte non lo fanno. La scelta sicura per l'interoperabilità è quella noiosa.

Vale la pena affrontare la questione di SHA-1 direttamente, perché lo strumento di hash di questo sito segna SHA-1 come rotto. Entrambe le affermazioni sono vere. SHA-1 è inservibile per le firme digitali perché gli attaccanti possono fabbricare collisioni — due documenti con lo stesso hash. TOTP non dipende da quella proprietà: la sua sicurezza viene dalla chiave segreta dentro l'HMAC, non dalla resistenza alle collisioni dell'hash, e HMAC-SHA-1 resta solido. Usare SHA-256 qui è difendibile ma rende poco, e costa interoperabilità con le app che fanno solo SHA-1.

Cosa protegge e cosa non protegge questo strumento

Tutto qui gira nel tuo browser. L'HMAC è calcolato con la Web Crypto API sul tuo dispositivo, lo stesso primitivo che usano gli strumenti di hash e HMAC, e nulla di ciò che digiti — segreto, codice o otpauth URI — viene caricato, memorizzato o registrato. È una proprietà del codice lato client, non una promessa da credere sulla parola.

Detto questo, un segreto TOTP è un secondo fattore: chiunque lo abbia può generare i tuoi codici. Incollare un segreto di produzione in qualsiasi pagina web — inclusa questa — lo mette negli appunti e forse nella cronologia del browser, quindi trattalo con la stessa cura di una password, e preferisci un segreto usa e getta o di test quando vuoi solo capire il meccanismo. Lo strumento esiste per il debug e per imparare, non per essere il luogo dove vive il tuo vero secondo fattore.