Ditt VPN-lösenord är bara så privat som dess verifierare

Gå igenom fyra frågor om varje VPN-inloggning: vad skyddar lösenordet under transporten, vilken komponent tar emot det, vad gör den komponenten med det, och vad lagras efteråt. Varje svar är en annan kontroll, och ett starkt svar på en säger ingenting om de andra. Misstaget är att behandla tunnelkryptering som om den täckte alla fyra. Den täcker den första, och bara den första.

Fråga vem som avslutar sessionen, inte om sessionen är krypterad.

Krypterat för vem, exakt?

TLS skyddar lösenordet mellan klienten och det som avslutar anslutningen. Om den ändpunkten är VPN-gatewayen ser gatewayens autentiseringskod lösenordet i klartext, validerar det och skickar vidare det eller ett härlett värde. Det är den avsedda designen, inte en läcka. En nätverksobservatör på vägen lär sig ingenting användbart, och komponenten som utför verifieringen lär sig allt den behöver.

Gemenskapen kring OpenVPN dokumenterar detta uttryckligen: auth-user-pass-verify lämnar över de inlämnade inloggningsuppgifterna till ett verifieringsskript eller insticksprogram. Det är en avsiktlig överlämning mellan komponenter, och den hör hemma i förtroendemodellen som en namngiven part.

Verifieraren ser lösenordet

När en komponent tar emot ett lösenord för att verifiera det, avgör dess åtkomstkontroller, loggning och kodkvalitet om hemligheten förblir innesluten. Ett skript som skriver inloggningsuppgifterna till en logg, eller ett insticksprogram som cachar dem, skapar en mycket större exponering än protokollet gjorde. Åtkomst beror på arkitektur och roller, inte på tunneln, och därför hör en tjänsteägare som kontrollerar verifieraren hemma i bedömningen.

Olika metoder exponerar olika material. Certifikatautentisering bevisar en privat nyckel utan att skicka den, och ett federationsflöde kan behålla lösenordet hos identitetsleverantören medan det utfärdar ett begränsat påstående till VPN:en. Dessa designer snävar in cirkeln; ingen av dem eliminerar varje betrodd part.

Lagrade hashar skyddar en annan fas

NIST:s vägledning skiljer skyddad överföring från motståndskraftig verifierarlagring. Salt och ett hashschema med kostnad hanterar hotet mot den lagrade verifieraren, vilket är det som händer i efterhand om en databas läcker. De gör ingenting för en körtidskomponent som måste ta emot indata för att jämföra dem. Att läsa vägledningen som om den lovade hemlighållande under körning är ett kategorifel.

Ett väl hashat lösenordslager och ett exponerat verifieringsskript kan därför samexistera i en och samma produkt utan motsägelse.

Välja en metod som snävar in cirkeln

Om kravet är att gatewayen aldrig tar emot ett återanvändbart lösenord, välj en metod som faktiskt garanterar det; att byta ett datachiffer skapar inte den egenskapen. Att verifiera VPN-serverns certifikat berättar vilken motpart du nådde; det säger ingenting om hur den motparten hanterar inloggningsuppgifter efteråt. Behåll serververifieringen, använd separata inloggningsuppgifter per tjänst och följ organisationens stödda identitetsflöde.

Notera parten som tar emot lösenordet, parten som validerar det och formen i vilken det förvaras. De tre svaren hör till bredvid anslutningsprofilen, eftersom de överlever varje enskild tunnel.

Den användbara frågan är inte om lösenordet är krypterat, utan för vem det är dolt, vilken komponent som tar emot det och vilken form som överlever efteråt.