La tua password VPN è privata solo quanto il suo verificatore

Esamina quattro domande su qualsiasi accesso VPN: cosa protegge la password durante il transito, quale componente la riceve, cosa ne fa quel componente e cosa viene memorizzato dopo. Ogni risposta è un controllo diverso, e una risposta solida a una non dice nulla sulle altre. L’errore è trattare la crittografia del tunnel come se coprisse tutte e quattro. Copre la prima, e solo la prima.

Chiedi chi termina la sessione, non se la sessione è cifrata.

Cifrata per chi, esattamente?

TLS protegge la password tra il client e ciò che termina la connessione. Se quell’estremità è il gateway VPN, il codice di autenticazione del gateway vede la password in chiaro, la convalida e trasmette oltre essa o un valore derivato. È la progettazione prevista, non una fuga. Un osservatore di rete sul percorso non apprende nulla di utile, e il componente che esegue la verifica apprende tutto ciò che gli serve.

La comunità di OpenVPN lo documenta esplicitamente: auth-user-pass-verify consegna le credenziali inviate a uno script o a un plugin di verifica. È un passaggio intenzionale tra componenti, e appartiene al modello di fiducia come parte nominata.

Il verificatore vede la password

Una volta che un componente riceve una password per verificarla, i suoi controlli di accesso, la registrazione e la qualità del codice decidono se il segreto resta confinato. Uno script che scrive la credenziale in un registro, o un plugin che la memorizza nella cache, crea un’esposizione molto maggiore di quella del protocollo. L’accesso dipende dall’architettura e dai ruoli, non dal tunnel, per questo il proprietario del servizio che controlla il verificatore rientra nella valutazione.

Metodi diversi espongono materiale diverso. L’autenticazione tramite certificato dimostra una chiave privata senza inviarla, e un flusso di federazione può mantenere la password presso il provider di identità emettendo un’asserzione limitata alla VPN. Questi progetti restringono il cerchio; nessuno di essi elimina ogni parte fidata.

Gli hash memorizzati proteggono una fase diversa

Le linee guida NIST separano la trasmissione protetta dalla memorizzazione resistente del verificatore. Il salting e uno schema di hashing costoso affrontano la minaccia del verificatore memorizzato, cioè ciò che accade a posteriori se un database trapela. Non fanno nulla per un componente in fase di esecuzione che deve ricevere l’input per confrontarlo. Leggere le linee guida come se promettessero segretezza in esecuzione è un errore di categoria.

Un archivio di password ben hashato e uno script di verifica esposto possono quindi convivere nello stesso prodotto senza contraddizione.

Scegliere un metodo che restringe il cerchio

Se il requisito è che il gateway non riceva mai una password riutilizzabile, scegli un metodo che lo garantisca davvero; cambiare un cifrario dei dati non crea questa proprietà. Verificare il certificato del server VPN ti dice a quale peer sei arrivato; non dice nulla su come quel peer tratti le credenziali in seguito. Mantieni la verifica del server, usa credenziali distinte per servizio e segui il flusso di identità supportato dall’organizzazione.

Annota la parte che riceve la password, la parte che la convalida e la forma in cui viene conservata. Queste tre risposte stanno accanto al profilo di connessione, perché sopravvivono a qualsiasi tunnel particolare.

La domanda utile non è se la password sia cifrata, ma da chi è nascosta, quale componente la riceve e quale forma sopravvive dopo.