VPN-passordet ditt er berre så privat som verifikatoren

Gå gjennom fire spørsmål om kvar einaste VPN-innlogging: kva vernar passordet under transporten, kva komponent mottek det, kva gjer den komponenten med det, og kva blir lagra etterpå. Kvart svar er ein annan kontroll, og eit sterkt svar på eitt seier ingenting om dei andre. Feilen er å handsame tunnelkryptering som om ho dekkjer alle fire. Ho dekkjer den første, og berre den første.

Spør kven som avsluttar økta, ikkje om økta er kryptert.

Kryptert for kven, nøyaktig?

TLS vernar passordet mellom klienten og det som avsluttar sambandet. Viss endepunktet er VPN-gatewayen, ser autentiseringskoden til gatewayen passordet i klartekst, validerer det og sender det eller ein avleidd verdi vidare. Det er den tilsikta utforminga, ikkje ein lekkasje. Ein nettverksobservatør på vegen lærer ingenting nyttig, og komponenten som utfører verifiseringa, lærer alt han treng.

Miljøet bak OpenVPN dokumenterer dette eksplisitt: auth-user-pass-verify overleverer dei innsende påloggingsdetaljane til eit verifiseringsskript eller programtillegg. Det er ei medviten overlevering mellom komponentar, og ho høyrer heime i tillitsmodellen som ein namngjeven part.

Verifikatoren ser passordet

Når ein komponent mottek eit passord for å verifisere det, avgjer tilgangskontrollane, logginga og kodekvaliteten hans om hemmelegheita blir verande innelukka. Eit skript som skriv påloggingsdetaljane til ein logg, eller eit programtillegg som bufrer dei, skaper ei langt større eksponering enn protokollen gjorde. Tilgang avheng av arkitektur og roller, ikkje av tunnelen, og difor høyrer ein tenesteeigar som kontrollerer verifikatoren med i vurderinga.

Ulike metodar avdekkjer ulikt materiale. Sertifikatautentisering provar ein privat nøkkel utan å sende han, og ein føderasjonsflyt kan halde passordet hos identitetsleverandøren medan han gjev ut ein avgrensa påstand til VPN-en. Desse utformingane snevrar inn sirkelen; ingen av dei fjernar kvar einaste betrudd part.

Lagra hashar vernar ein annan fase

NIST-retningslinjene skil verna overføring frå motstandsdyktig verifikatorlagring. Salting og eit hashskjema med kostnad handterer trugselen mot den lagra verifikatoren, som er det som skjer i ettertid viss ei database lekk. Dei gjer ingenting for ein køyretidskomponent som må motta inndata for å samanlikne dei. Å lese retningslinjene som om dei lova hemmeleghald under køyring, er ein kategorifeil.

Eit godt hasha passordlager og eit eksponert verifiseringsskript kan difor sameksistere i eitt produkt utan motseiing.

Velje ein metode som snevrar inn sirkelen

Viss kravet er at gatewayen aldri mottek eit gjenbrukbart passord, vel ein metode som faktisk garanterer det; å byte ein datasiffer skaper ikkje den eigenskapen. Verifisering av sertifikatet til VPN-serveren fortel deg kva motpart du nådde; det seier ingenting om korleis den motparten handterer påloggingsdetaljar etterpå. Hald på serververifiseringa, bruk ulike påloggingsdetaljar per teneste, og fylg den støtta identitetsflyten til organisasjonen.

Noter parten som mottek passordet, parten som validerer det, og forma det blir oppbevart i. Dei tre svara høyrer til ved sida av tilkoplingsprofilen, fordi dei overlever kvar einaste bestemte tunnel.

Det nyttige spørsmålet er ikkje om passordet er kryptert, men for kven det er skjult, kva komponent som mottek det, og kva form som overlever etterpå.