Dove finisce il codice della sfida statica in un accesso OpenVPN

Il client mostra una seconda casella dopo il campo della password, si digita il codice del token hardware, e l’accesso fallisce ancora con un errore di autenticazione. Quella casella esiste, quindi il profilo l’ha richiesta. Se il server abbia mai ricevuto il valore in una forma che comprende è un’altra domanda, ed è quella a cui conviene rispondere per prima.

Partite dal messaggio che il vostro client mostra davvero

Un profilo può portare una direttiva di sfida statica con una stringa di messaggio e un flag che controlla se la risposta viene mostrata durante la digitazione. Il messaggio è ciò che vedete nella finestra di dialogo; il flag è una preferenza di visualizzazione per lo stesso input. Nessuno dei due dice al server come verificare qualcosa.

Contate i campi che vi sono stati realmente dati. Un campo per un nome utente più un campo mascherato è un normale accesso con password senza alcuna sfida. Un secondo campo che appare dopo la password, con la propria etichetta, è il client che implementa l’interazione della sfida.

Se la seconda casella non appare mai nel client che usate, quel client potrebbe non implementare l’interazione, oppure implementarla solo tramite un’altra interfaccia, come un’interfaccia di gestione. Controllare il client costa meno che riscrivere il profilo, ed è di solito lì che si trova davvero la discrepanza.

Ciò che il server deve già supportare

Il profilo descrive ciò che il client deve raccogliere. Non attiva la verifica sul server, e un server privo dell’integrazione di autenticazione corrispondente riceverà semplicemente una password che non riconosce. Ecco perché alcuni deployment mostrano il messaggio e rifiutano ogni codice, ed ecco perché la risposta dell’operatore su quale meccanismo esegue il controllo è quella che conta.

Chiedete all’operatore quale meccanismo esegue il controllo. Può essere un plugin che parla con PAM, un hook di script che convalida la risposta contro un servizio di token, o un’integrazione basata sulla gestione che analizza da sé il valore impacchettato. Ognuno di essi si aspetta un input leggermente diverso.

Qui vanno anche calibrate le aspettative. Un secondo messaggio è un meccanismo di input, non la prova che un secondo fattore sia applicato, perché l’applicazione avviene lato server e si vede solo quando provate un codice errato.

Il campo codificato che invia l’interfaccia di gestione

Quando un’interfaccia pilota la connessione tramite l’interfaccia di gestione, la password e la risposta alla sfida vengono impacchettate in un unico valore prima dell’invio. La documentazione dell’interfaccia di gestione descrive il formato: un prefisso, poi la password e la risposta come componenti Base64 separati.

Base64 è una codifica, non una protezione. Non nasconde nulla a chi può leggere il campo, e non trasforma un codice monouso in qualcosa di riutilizzabile. Il valore impacchettato merita lo stesso trattamento di una password: fuori dai profili condivisi, fuori dalle righe di comando e fuori dai log diagnostici.

Quella codifica è anche la fonte di confusione più comune, perché ora ci sono tre forme che sembrano simili e non sono intercambiabili. Un semplice file di credenziali contiene una password. Una concatenazione letterale di password e codice contiene una stringa diversa. La risposta impacchettata di un client di gestione ne contiene una terza. Confermate quale si aspetta il vostro percorso di verifica prima di cambiare un campo solo perché un errore è sparito.

Statica contro dinamica: tempi diversi

Una sfida statica è nota prima che venga inviata la prima credenziale, quindi il client può chiederla in anticipo. Una sfida dinamica arriva più tardi, inviata dal flusso di autenticazione dopo che uno scambio è già iniziato, e richiede un client capace di gestire una richiesta a metà conversazione.

Il supporto dell’una non dà l’altra. Una direttiva di profilo che configura un messaggio statico non implementa una sfida avviata dal server, e un’interfaccia che gestisce richieste dinamiche potrebbe comunque non mostrarne una statica. Leggere quale lato ha avviato la richiesta è il modo più rapido per distinguerle.

Il funzionamento senza supervisione è il punto in cui questo diventa una questione di progettazione e non di interfaccia. Un codice salvato non è una credenziale durevole all’avvio, e una riconnessione ore dopo richiederà un input nuovo, a meno che il deployment supporti una disposizione di token che l’operatore abbia abilitato deliberatamente.

Provate sia il successo sia l’errore, non solo la finestra di dialogo

Eseguite entrambe le metà della prova. Credenziali corrette con una risposta valida dovrebbero riuscire; credenziali corrette con una risposta deliberatamente errata dovrebbero essere rifiutate. Se entrambe riescono, il client raccoglie un input che nulla verifica, e la finestra di dialogo è stata scambiata per un controllo. Quella singola prova intercetta più deployment di qualsiasi revisione del profilo.

Poi ripetete la connessione dopo una riconnessione, con un account non registrato, e attraverso il client che i vostri utenti eseguono davvero. La comparsa del messaggio è un comportamento del client; il rifiuto di un codice errato è il server che applica qualcosa.