Din VPN-adgangskode er kun så privat som dens verifikator

Gå gennem fire spørgsmål om ethvert VPN-login: hvad beskytter adgangskoden under transporten, hvilken komponent modtager den, hvad gør denne komponent med den, og hvad gemmes der bagefter. Hvert svar er en anden kontrol, og et stærkt svar på ét siger intet om de andre. Fejlen er at behandle tunnelkryptering, som om den dækkede alle fire. Den dækker det første og kun det første.

Spørg, hvem der afslutter sessionen, i stedet for om sessionen er krypteret.

Krypteret til hvem, præcis?

TLS beskytter adgangskoden mellem klienten og det, der afslutter forbindelsen. Hvis det endepunkt er VPN-gatewayen, ser gatewayens godkendelseskode adgangskoden i klartekst, validerer den og sender den eller en afledt værdi videre. Det er det tilsigtede design, ikke en lækage. En netværksobservatør på vejen lærer intet nyttigt, og komponenten, der udfører verifikationen, lærer alt, hvad den har brug for.

Fællesskabet bag OpenVPN dokumenterer dette udtrykkeligt: auth-user-pass-verify overdrager de indsendte legitimationsoplysninger til et verifikationsscript eller plugin. Det er en bevidst overdragelse mellem komponenter, og den hører til i tillidsmodellen som en navngivet part.

Verifikatoren ser adgangskoden

Når en komponent modtager en adgangskode for at verificere den, afgør dens adgangskontroller, logning og kodekvalitet, om hemmeligheden forbliver indelukket. Et script, der skriver legitimationsoplysningerne i en log, eller et plugin, der cacher dem, skaber en langt større eksponering, end protokollen gjorde. Adgang afhænger af arkitektur og roller snarere end af tunnelen, og derfor hører en tjenesteejer, der kontrollerer verifikatoren, med i vurderingen.

Forskellige metoder blotlægger forskelligt materiale. Certifikatgodkendelse beviser en privat nøgle uden at sende den, og et føderationsflow kan beholde adgangskoden hos identitetsudbyderen og samtidig udstede en afgrænset erklæring til VPN'en. De design indsnævrer kredsen; ingen af dem fjerner enhver betroet part.

Gemte hashværdier beskytter en anden fase

NIST's vejledning adskiller beskyttet transmission fra modstandsdygtig verifikatorlagring. Salt og et hash-skema med omkostninger håndterer truslen mod den gemte verifikator, som er det, der sker bagefter, hvis en database lækker. De gør intet ved en runtime-komponent, der skal modtage input for at sammenligne det. At læse vejledningen, som om den lovede hemmeligholdelse under kørsel, er en kategorifejl.

Et godt hashet adgangskodelager og et eksponeret verifikationsscript kan derfor sameksistere i ét produkt uden modsigelse.

Vælg en metode, der indsnævrer kredsen

Hvis kravet er, at gatewayen aldrig modtager en genbrugelig adgangskode, så vælg en metode, der faktisk garanterer det; at skifte en datachiffer skaber ikke den egenskab. Verifikation af VPN-serverens certifikat fortæller dig, hvilken peer du nåede; det siger intet om, hvordan den peer bagefter håndterer legitimationsoplysninger. Behold serververifikationen, brug forskellige legitimationsoplysninger pr. tjeneste, og følg organisationens understøttede identitetsflow.

Notér den part, der modtager adgangskoden, den part, der validerer den, og den form, hvori den opbevares. De tre svar hører ved siden af forbindelsesprofilen, fordi de overlever enhver bestemt tunnel.

Det nyttige spørgsmål er ikke, om adgangskoden er krypteret, men for hvem den er skjult, hvilken komponent der modtager den, og hvilken form der overlever bagefter.