Uw VPN-wachtwoord is slechts zo privé als de verifieerder ervan

Loop vier vragen door over elke VPN-login: wat beschermt het wachtwoord tijdens transport, welk onderdeel ontvangt het, wat doet dat onderdeel ermee, en wat wordt daarna opgeslagen. Elk antwoord is een andere maatregel, en een sterk antwoord op één zegt niets over de andere. De fout is tunnelversleuteling te behandelen alsof die alle vier dekt. Ze dekt de eerste, en alleen de eerste.

Vraag wie de sessie beëindigt, niet of de sessie versleuteld is.

Versleuteld voor wie, precies?

TLS beschermt het wachtwoord tussen de client en wat de verbinding beëindigt. Als dat eindpunt de VPN-gateway is, ziet de authenticatiecode van de gateway het wachtwoord als platte tekst, valideert het en geeft het of een afgeleide waarde door. Dat is het bedoelde ontwerp, geen lek. Een netwerkwaarnemer op het pad leert niets nuttigs, en het onderdeel dat de verificatie uitvoert, leert alles wat het nodig heeft.

De gemeenschap rond OpenVPN documenteert dit expliciet: auth-user-pass-verify draagt de ingediende inloggegevens over aan een verificatiescript of plug-in. Het is een bewuste overdracht tussen onderdelen, en ze hoort als benoemde partij in het vertrouwensmodel.

De verifieerder ziet het wachtwoord

Zodra een onderdeel een wachtwoord ontvangt om het te verifiëren, bepalen de toegangscontroles, logging en codekwaliteit ervan of het geheim binnenblijft. Een script dat de inloggegevens in een log schrijft, of een plug-in die ze cachet, veroorzaakt een veel grotere blootstelling dan het protocol deed. Toegang hangt af van architectuur en rollen, niet van de tunnel, daarom hoort een diensteigenaar die de verifieerder beheert in de beoordeling.

Verschillende methoden leggen verschillend materiaal bloot. Certificaatauthenticatie bewijst een privésleutel zonder die te versturen, en een federatieflow kan het wachtwoord bij de identiteitsprovider houden terwijl hij een beperkte bewering aan de VPN uitgeeft. Die ontwerpen verkleinen de kring; geen ervan schrapt elke vertrouwde partij.

Opgeslagen hashes beschermen een andere fase

De NIST-richtlijnen scheiden beveiligde overdracht van veerkrachtige verifieerderopslag. Zout en een kostbaar hashschema pakken de dreiging van de opgeslagen verifieerder aan, dat is wat achteraf gebeurt als een database uitlekt. Ze doen niets voor een runtime-onderdeel dat de invoer moet ontvangen om die te vergelijken. De richtlijnen lezen alsof ze geheimhouding tijdens runtime beloven, is een categoriefout.

Een goed gehashte wachtwoordopslag en een blootgesteld verificatiescript kunnen dus zonder tegenspraak in één product bestaan.

Een methode kiezen die de kring verkleint

Als de eis is dat de gateway nooit een herbruikbaar wachtwoord ontvangt, kies dan een methode die dat echt garandeert; een gegevenscijfer wijzigen creëert die eigenschap niet. Het certificaat van de VPN-server verifiëren vertelt u welke peer u bereikte; het zegt niets over hoe die peer daarna met inloggegevens omgaat. Behoud serververificatie, gebruik aparte inloggegevens per dienst, en volg de door de organisatie ondersteunde identiteitsflow.

Noteer de partij die het wachtwoord ontvangt, de partij die het valideert en de vorm waarin het wordt bewaard. Die drie antwoorden horen naast het verbindingsprofiel, omdat ze elke specifieke tunnel overleven.

De nuttige vraag is niet of het wachtwoord versleuteld is, maar voor wie het verborgen is, welk onderdeel het ontvangt en welke vorm daarna overleeft.