Vaša VPN lozinka privatna je onoliko koliko i njen verifikator
Šifrovanje tunela pokriva samo fazu prenosa. Komponenta koja provjerava lozinku i dalje je prima, a sačuvani heš u potpunosti štiti kasniju fazu.
Prođite kroz četiri pitanja o bilo kojoj VPN prijavi: šta štiti lozinku tokom prenosa, koja komponenta je prima, šta ta komponenta s njom radi i šta se poslije pohranjuje. Svaki odgovor je druga kontrola, a jak odgovor na jedno pitanje ne govori ništa o ostalima. Greška je tretirati šifrovanje tunela kao da pokriva sva četiri. Ono pokriva prvo, i samo prvo.
Pitajte ko prekida sesiju, a ne da li je sesija šifrovana.
Šifrovano za koga, tačno?
TLS štiti lozinku između klijenta i onoga što prekida vezu. Ako je ta krajnja tačka VPN gateway, autentifikacijski kod gatewaya vidi lozinku u čistom tekstu, validira je i prosljeđuje dalje nju ili izvedenu vrijednost. To je predviđeni dizajn, a ne curenje. Mrežni posmatrač na putu ne nauči ništa korisno, a komponenta koja obavlja verifikaciju nauči sve što joj treba.
OpenVPN zajednica to eksplicitno dokumentuje: auth-user-pass-verify predaje dostavljene akreditive skripti ili dodatku za verifikaciju. To je namjerno predavanje između komponenti i pripada modelu povjerenja kao imenovana strana.
Verifikator vidi lozinku
Kada komponenta primi lozinku da bi je provjerila, o kontrolama pristupa, evidentiranju i kvalitetu koda te komponente zavisi da li tajna ostaje zatvorena. Skripta koja upisuje akreditive u dnevnik ili dodatak koji ih kešira stvara daleko veću izloženost nego što je protokol stvorio. Pristup zavisi od arhitekture i uloga, a ne od tunela, zbog čega vlasnik usluge koji kontroliše verifikator pripada procjeni.
Različite metode izlažu različit materijal. Autentifikacija certifikatom dokazuje privatni ključ bez slanja, a federacijski tok može zadržati lozinku kod provajdera identiteta uz izdavanje ograničene tvrdnje VPN-u. Ti dizajni sužavaju krug; nijedan od njih ne uklanja svaku pouzdanu stranu.
Sačuvani heševi štite drugu fazu
NIST smjernice razdvajaju zaštićeni prenos od otpornog skladištenja verifikatora. Soljenje i hash šema s troškom rješavaju prijetnju sačuvanog verifikatora, a to je ono što se dogodi naknadno ako baza podataka procuri. One ne čine ništa za runtime komponentu koja mora primiti unos da bi ga uporedila. Čitati smjernice kao da obećavaju tajnost u radu je greška kategorije.
Dobro heširano skladište lozinki i izložena verifikacijska skripta stoga mogu nesmetano postojati u istom proizvodu.
Odabir metode koja sužava krug
Ako je zahtjev da gateway nikada ne primi lozinku koja se može ponovo koristiti, odaberite metodu koja to zaista garantuje; promjena šifre podataka ne stvara to svojstvo. Provjera certifikata VPN servera govori vam do kojeg ste partnera došli; ne govori ništa o tome kako taj partner poslije postupa s akreditivima. Zadržite provjeru servera, koristite različite akreditive za svaku uslugu i slijedite tok identiteta koji organizacija podržava.
Zabilježite stranu koja prima lozinku, stranu koja je validira i oblik u kojem se čuva. Ta tri odgovora pripadaju uz profil veze, jer nadživljavaju svaki pojedini tunel.
Korisno pitanje nije da li je lozinka šifrovana, nego od koga je skrivena, koja je komponenta prima i koji oblik poslije ostaje.