VPN-passordet ditt er bare så privat som verifikatoren

Gå gjennom fire spørsmål om enhver VPN-innlogging: hva beskytter passordet under transporten, hvilken komponent mottar det, hva gjør den komponenten med det, og hva lagres etterpå. Hvert svar er en annen kontroll, og et sterkt svar på ett sier ingenting om de andre. Feilen er å behandle tunnelkryptering som om den dekket alle fire. Den dekker den første, og bare den første.

Spør hvem som avslutter økten, ikke om økten er kryptert.

Kryptert for hvem, nøyaktig?

TLS beskytter passordet mellom klienten og det som avslutter forbindelsen. Hvis endepunktet er VPN-gatewayen, ser gatewayens autentiseringskode passordet i klartekst, validerer det og sender det eller en avledet verdi videre. Det er den tilsiktede designen, ikke en lekkasje. En nettverksobservatør på veien lærer ingenting nyttig, og komponenten som utfører verifiseringen, lærer alt den trenger.

Miljøet bak OpenVPN dokumenterer dette eksplisitt: auth-user-pass-verify overleverer de innsendte påloggingsdetaljene til et verifiseringsskript eller programtillegg. Det er en bevisst overlevering mellom komponenter, og den hører hjemme i tillitsmodellen som en navngitt part.

Verifikatoren ser passordet

Når en komponent mottar et passord for å verifisere det, avgjør dens tilgangskontroller, logging og kodekvalitet om hemmeligheten forblir innelukket. Et skript som skriver påloggingsdetaljene til en logg, eller et programtillegg som bufrer dem, skaper en langt større eksponering enn protokollen gjorde. Tilgang avhenger av arkitektur og roller, ikke av tunnelen, og derfor hører en tjenesteeier som kontrollerer verifikatoren med i vurderingen.

Ulike metoder avdekker ulikt materiale. Sertifikatautentisering beviser en privat nøkkel uten å sende den, og en føderasjonsflyt kan beholde passordet hos identitetsleverandøren mens den utsteder en avgrenset påstand til VPN-en. Disse designene snevrer inn sirkelen; ingen av dem fjerner enhver betrodd part.

Lagrede hasher beskytter en annen fase

NISTs veiledning skiller beskyttet overføring fra motstandsdyktig verifikatorlagring. Salting og et hashskjema med kostnad håndterer trusselen mot den lagrede verifikatoren, som er det som skjer i ettertid hvis en database lekker. De gjør ingenting for en kjøretidskomponent som må motta inndataene for å sammenligne dem. Å lese veiledningen som om den lovet hemmelighold under kjøring, er en kategorifeil.

Et godt hashet passordlager og et eksponert verifiseringsskript kan derfor sameksistere i ett produkt uten motsigelse.

Velge en metode som snevrer inn sirkelen

Hvis kravet er at gatewayen aldri mottar et gjenbrukbart passord, velg en metode som faktisk garanterer det; å bytte en datasiffer skaper ikke den egenskapen. Verifisering av VPN-serverens sertifikat forteller deg hvilken motpart du nådde; det sier ingenting om hvordan den motparten håndterer påloggingsdetaljer etterpå. Behold serververifiseringen, bruk ulike påloggingsdetaljer per tjeneste, og følg organisasjonens støttede identitetsflyt.

Noter parten som mottar passordet, parten som validerer det, og formen det oppbevares i. De tre svarene hører til ved siden av tilkoblingsprofilen, fordi de overlever enhver bestemt tunnel.

Det nyttige spørsmålet er ikke om passordet er kryptert, men for hvem det er skjult, hvilken komponent som mottar det, og hvilken form som overlever etterpå.