Perché un codice monouso valido fallisce comunque all'accesso VPN

Apri il client VPN, digiti la password e le sei cifre dell'autenticatore tornano come non valide — due volte, poi una terza. Sull'account non è cambiato nulla da ieri, quindi l'istinto è cancellare la voce nell'autenticatore e scansionarla di nuovo — di solito è la riparazione sbagliata. Un codice monouso non è una seconda password: il gateway deve chiederlo in un passaggio preciso, da una voce registrata precisa, dentro una finestra precisa, e la maggior parte dei rifiuti avviene prima che le cifre vengano confrontate. Stabilisci in quale passaggio ti trovi prima di toccare la registrazione.

L'ordine delle richieste dice in quale flusso sei

Tre forme coprono quasi ogni accesso VPN che comporta un codice. Nella forma a due passaggi il client invia la password, il server emette una sfida e il client chiede di nuovo. Nella forma combinata il gateway vuole password e codice in un'unica sottomissione — a volte concatenati, a volte dopo un separatore che solo l'operatore documenta. Nella forma browser il client non ha alcun campo: il codice va in una pagina web, oppure un'approvazione push lo sostituisce, e il client desktop attende il risultato.

La forma sbagliata sembra un codice scadente. Incolla un codice nuovo in un campo riservato alla password e il server lo leggerà come parte della password. Lato client, OpenVPN 2.4 e successivi rendono visibile la differenza: un server che risponde con AUTH_FAILED,CRV1: si aspetta una risposta alla sfida, quindi il profilo necessita di static-challenge o di un file di password in forma SCRV1:. Un profilo più vecchio che porta solo auth-user-pass autentica la password e poi si blocca, cosa che nel registro sembra un guasto OTP anche se non è stato inviato alcun codice.

Vale la pena citare WireGuard come eccezione: autentica coppie di chiavi, non persone, quindi non c'è alcun campo per un codice. Se un fornitore ne annuncia uno, qualcosa fuori dal tunnel lo accetta.

Cosa fa il server con le sei cifre

I codici basati sul tempo seguono RFC 6238, che avvolge la più antica costruzione a contatore di RFC 4226: un HMAC su un fattore mobile, troncato a sei cifre per impostazione predefinita. Per TOTP il fattore mobile è l'ora Unix corrente divisa per un passo, 30 secondi salvo che l'operatore l'abbia modificato. Il verificatore non confronta mai le tue cifre con un valore memorizzato; ricalcola il codice atteso dal seme condiviso e normalmente accetta anche i passi vicini, così un andata e ritorno lento non fa fallire l'accesso.

Due conseguenze passano inosservate. Il fuso orario del telefono è irrilevante, perché il seme non vede mai un orologio locale — conta solo lo scostamento dall'UTC reale, e un dispositivo che va due minuti avanti fallisce a ogni codice mentre mostra un conto alla rovescia pulito. E un codice è monouso per progettazione: il verificatore ricorda l'ultimo valore di contatore accettato per quel seme, quindi le stesse cifre inviate di nuovo vengono rifiutate anche dentro la stessa finestra. Un client che riprova dopo un timeout può bruciare il codice appena inviato.

I token basati su contatore spostano il contatore a ogni pressione, quindi escono dalla sincronizzazione dopo che sono stati generati codici mai inviati; la riparazione abituale è una finestra di risincronizzazione che accetta alcuni valori in anticipo. Se l'operatore ha registrato HOTP e la tua applicazione mostra TOTP, ogni valore è sbagliato in un modo che sembra un problema di orologio. L'URI di provisioning dietro il codice QR indica tipo, cifre, periodo e hash.

Guasti che sembrano un codice sbagliato

La voce registrata è il colpevole più comune. Le applicazioni di autenticazione etichettano le voci per emittente e account, quindi chi ha due identità sullo stesso VPN può ritrovarsi con due voci le cui etichette differiscono di un carattere. Un codice è valido per il seme che lo ha generato e per nient'altro. Confronta l'etichetta sul telefono con il nome utente che il server registra, non con quello che ricordi di aver digitato.

Secondo, un insieme di parametri che non corrisponde. Un seme registrato con otto cifre, un periodo di 60 secondi o SHA-256 produce codici che un verificatore che si aspetta sei cifre, 30 secondi e SHA-1 rifiuta, e lato client questo è indistinguibile da un codice sbagliato. Compare dopo migrazioni in cui la voce è stata aggiunta di nuovo da una foto del codice QR, o in cui il record del token è stato ricostruito con i valori predefiniti.

Terzo, non riguarda il codice. I gateway restituiscono di solito un unico errore di autenticazione generico per password sbagliata, codice scaduto e account disattivato, di proposito, così nessuno può sondare quale fattore abbia fallito. Leggi il registro del gateway o di RADIUS invece del messaggio del client: una sfida mai emessa, un rifiuto di accesso senza attributo OTP e una negazione per policy appaiono uguali sullo schermo e portano a passaggi successivi diversi.

Una breve sequenza che lo circoscrive

Inizia dal controllo meno costoso e fermati al primo passaggio che non regge.

1. Attendi un codice nuovo, invialo una volta e nota se la sfida compare prima o dopo l'accettazione della password.
2. Abbina l'etichetta nell'autenticatore al nome utente che il server memorizza.
3. Verifica che il profilo possa rispondere a una sfida, come nel caso CRV1 qui sopra.
4. Confronta l'orologio del dispositivo con una fonte di tempo nota; uno scostamento oltre qualche decina di secondi rompe TOTP da solo.
5. Chiedi all'operatore se il token è TOTP o HOTP, e quali cifre, periodo e hash sono stati registrati.

Due regole impediscono che questo peggiori le cose. Non riprovare molte volte: molti gateway contano i fallimenti per account e o lo bloccano o iniziano a ritardare le risposte, così una raffica trasforma un piccolo errore di configurazione in un ticket di supporto. E non registrare di nuovo il token come diagnostica, perché invalida il vecchio seme; se il guasto reale era una sfida che il client non ha mai inviato, ora hai due modifiche da giustificare invece di una.

Tieni il seme e i codici di recupero fuori dal circuito

Le sei cifre e il segreto che vi sta dietro non sono intercambiabili. Un codice QR di provisioning o un seme Base32 genera ogni codice futuro dell'account, quindi appartiene alla stessa categoria della password: non in uno screenshot, non in un commento di un ticket, non in una chat con qualcuno che ti ha contattato per primo. I codici di recupero sono un meccanismo separato — monouso, spesso saltano del tutto la richiesta del codice, e spenderne uno per provare l'account elimina una via di riserva che potresti servirti più avanti.

Un codice non rende nemmeno affidabile una pagina di accesso: una richiesta OTP su un dominio simile raccoglie un codice valido e lo riproduce dentro la finestra, e il certificato resta ciò che ti dice dove stai digitando.

Se la sequenza finisce su un profilo che non può rispondere a una sfida, correggi il profilo e riprova con un codice nuovo. Se finisce su parametri di registrazione non corrispondenti, chiedi all'operatore di leggere il record del token prima che qualcuno scansioni qualcosa. Se finisce su un blocco, aspetta che passi invece di cambiare client — è lo stato dell'account l'ostacolo, non l'applicazione.