Prima il metodo EAP: quale hash di password può usare una VPN
Una VPN verifica il segreto, non l'hash web. Leggi il metodo, poi controlla cosa contiene l'archivio prima di promettere che le stesse password continueranno a funzionare.
Molti team hanno un accesso web che funziona e una VPN che rifiuta ogni password della stessa tabella. L'applicazione web confronta un hash che ha calcolato da sé, mentre il tunnel chiede al client di dimostrare il possesso di un segreto in un modo che il server deve poter verificare. Sono requisiti diversi sul materiale memorizzato. È proprio nel divario tra i due che la maggior parte di questi progetti si blocca.
Leggi il metodo, poi lo schema
Annota quale prova richiede il metodo scelto prima di guardare qualsiasi schema. Un metodo challenge-response ha bisogno di materiale da cui il server possa calcolare la risposta attesa, che in pratica significa la password o una forma derivata compatibile. Un metodo che porta la password dentro un tunnel protetto ha bisogno della password stessa presso il verificatore. Leggi la documentazione del metodo per il requisito del verificatore e non per la configurazione del client, perché i requisiti del client sono di solito la parte facile.
Un hash con sale prodotto da un framework web moderno non fornisce nessuna delle due cose. Verifica un confronto specifico e non può essere riportato al segreto da cui è nato.
Il challenge-response non può usare un hash con sale
MSCHAPv2 è uno scambio challenge-response, quindi il server non riceve mai la password e non può confrontare una stringa memorizzata. Deve derivare la risposta attesa dal materiale che già possiede, ed è per questo che le forme memorizzate compatibili sono così strette. Un valore bcrypt o Argon2 con un sale per utente è unidirezionale in un modo che esclude del tutto lo scambio. La tabella qui sotto parte dalla forma di archiviazione e non dal nome del metodo, perché è la forma di archiviazione a decidere la risposta.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
La documentazione del plugin SQL per strongSwan definisce uno schema proprio per la configurazione e le credenziali, e il progetto segnala ancora quel plugin come sperimentale. Nulla in essa si adatta alla tabella utenti di un'applicazione né indovina quale schema di hashing abbia prodotto un valore memorizzato. Le opzioni realistiche sono quindi la migrazione verso un archivio che il gateway possa usare, o un servizio di autenticazione davanti all'archivio esistente che possa eseguire lo scambio. Qualunque altra cosa è un connettore con un'assunzione nascosta dentro.
RADIUS sposta il lavoro, non il requisito
Delegare EAP a un server RADIUS cambia dove avviene la verifica e di solito migliora la traccia di controllo. Non recupera una password da un hash unidirezionale, quindi il servizio di autenticazione ha ancora bisogno di materiale compatibile con il metodo che termina. I team lo scoprono dopo aver costruito il percorso RADIUS e aver incontrato lo stesso muro dall'altra parte.
Dove il server RADIUS può leggere una directory che contiene una credenziale compatibile, il progetto funziona e il gateway VPN resta semplice. Dove non può, la risposta onesta è un cambio di registrazione e non un altro connettore. Il provisioning e la revoca appartengono a chi possiede l'identità, quindi una tabella copiata senza un processo di sincronizzazione supportato è un secondo ciclo di vita delle credenziali e non un accesso unico. Va alla deriva la prima volta che qualcuno reimposta una password in un solo posto, e la deriva resta silenziosa finché un account presente in entrambi i sistemi non si comporta diversamente in ciascuno.
Limita l'account che legge la directory a quella lettura e tienilo separato dall'account che il gateway usa per la propria configurazione. Un account amministrativo condiviso trasforma un progetto di sola lettura in un raggio d'impatto molto più ampio.
Dove dovrebbe vivere l'account
Una volta risolta la questione del materiale, restano due architetture. Il gateway può possedere un piccolo archivio di credenziali che legge solo lui, oppure delegare a un servizio di autenticazione che si pone davanti alla directory aziendale.
La prima è più facile da ragionare e peggiore per l'utente, che finisce con una seconda password da mantenere. La seconda conserva una sola identità e aggiunge una dipendenza da un servizio che ora deve essere attivo prima che chiunque possa connettersi. Nessuna delle due è sbagliata, ma la scelta andrebbe annotata accanto alla configurazione del gateway, altrimenti il prossimo ingegnere darà per scontato che sia stata scelta l'altra. Qualunque cosa scegliate, i due comandi qui sotto sono quelli che mostrano lo stato attuale prima di cambiarlo.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsL'autenticazione dell'account non risolve nemmeno l'autorizzazione. L'appartenenza ai gruppi, lo stato del dispositivo e il permesso di rete richiedono ancora una mappatura esplicita dopo che l'utente ha dimostrato l'identità richiesta. Una connessione che si autentica perfettamente e non autorizza nulla è un risultato di policy, non un difetto del metodo.