Parola VPN este privată doar atât cât este verificatorul ei

Parcurgeți patru întrebări despre orice autentificare VPN: ce protejează parola în tranzit, ce componentă o primește, ce face acea componentă cu ea și ce se stochează după aceea. Fiecare răspuns este un control diferit, iar un răspuns solid la unul nu spune nimic despre celelalte. Greșeala este să tratați criptarea tunelului ca și cum le-ar acoperi pe toate patru. O acoperă pe prima, și doar pe prima.

Întrebați cine încheie sesiunea, nu dacă sesiunea este criptată.

Criptată pentru cine, mai exact?

TLS protejează parola între client și ceea ce încheie conexiunea. Dacă acel punct final este gateway-ul VPN, codul de autentificare al gateway-ului vede parola în text clar, o validează și transmite mai departe fie ea, fie o valoare derivată. Acesta este designul intenționat, nu o scurgere. Un observator de rețea de pe traseu nu află nimic util, iar componenta care face verificarea află tot ce îi trebuie.

Comunitatea OpenVPN documentează acest lucru explicit: auth-user-pass-verify predă credențialele trimise unui script sau plugin de verificare. Este o predare intenționată între componente și aparține modelului de încredere ca parte numită.

Verificatorul vede parola

Odată ce o componentă primește o parolă pentru a o verifica, controalele ei de acces, jurnalizarea și calitatea codului decid dacă secretul rămâne închis. Un script care scrie credențialele într-un jurnal, sau un plugin care le memorează în cache, creează o expunere mult mai mare decât a creat protocolul. Accesul depinde de arhitectură și roluri, nu de tunel, de aceea proprietarul serviciului care controlează verificatorul face parte din evaluare.

Metode diferite expun material diferit. Autentificarea prin certificat demonstrează o cheie privată fără a o trimite, iar un flux de federație poate păstra parola la furnizorul de identitate emițând totodată o afirmație limitată către VPN. Aceste modele îngustează cercul; niciunul nu elimină fiecare parte de încredere.

Hash-urile stocate protejează o altă etapă

Îndrumările NIST separă transmisia protejată de stocarea rezistentă a verificatorului. Sarea și o schemă de hash cu cost adresează amenințarea verificatorului stocat, adică ceea ce se întâmplă ulterior dacă o bază de date se scurge. Ele nu fac nimic pentru o componentă de rulare care trebuie să primească intrarea pentru a o compara. A citi îndrumările ca și cum ar promite secretul la rulare este o eroare de categorie.

Un depozit de parole bine hash-uit și un script de verificare expus pot, prin urmare, coexista în același produs fără contradicție.

Alegerea unei metode care îngustează cercul

Dacă cerința este ca gateway-ul să nu primească niciodată o parolă reutilizabilă, alegeți o metodă care garantează cu adevărat acest lucru; schimbarea unui cifru de date nu creează această proprietate. Verificarea certificatului serverului VPN vă spune la ce partener ați ajuns; nu spune nimic despre modul în care acel partener tratează credențialele după aceea. Păstrați verificarea serverului, folosiți credențiale distincte pentru fiecare serviciu și urmați fluxul de identitate susținut de organizație.

Înregistrați partea care primește parola, partea care o validează și forma în care este păstrată. Acele trei răspunsuri stau lângă profilul conexiunii, pentru că supraviețuiesc oricărui tunel anume.

Întrebarea utilă nu este dacă parola este criptată, ci de cine este ascunsă, ce componentă o primește și ce formă supraviețuiește după aceea.