A VPN-jelszava csak annyira bizalmas, mint a hitelesítője
Az alagút titkosítása csak az átviteli szakaszt fedi. A jelszót ellenőrző komponens továbbra is megkapja, és a tárolt hash egy teljesen későbbi szakaszt véd.
Menjen végig négy kérdésen bármely VPN-bejelentkezésnél: mi védi a jelszót átvitel közben, melyik komponens kapja meg, mit tesz vele az a komponens, és mi tárolódik utána. Minden válasz más kontroll, és az egyikre adott erős válasz semmit sem mond a többiről. A hiba az, hogy az alagút titkosítását úgy kezeljük, mintha mind a négyet fedné. Az elsőt fedi, és csak az elsőt.
Kérdezze meg, ki zárja le a munkamenetet, ne azt, hogy a munkamenet titkosított-e.
Titkosítva ki felé, pontosan?
A TLS a jelszót az ügyfél és a kapcsolatot lezáró fél között védi. Ha ez a végpont a VPN-átjáró, az átjáró hitelesítési kódja sima szövegben látja a jelszót, ellenőrzi, majd továbbadja azt vagy egy származtatott értéket. Ez a szándékolt kialakítás, nem szivárgás. Az útvonalon lévő hálózati megfigyelő semmi hasznosat nem tud meg, az ellenőrzést végző komponens pedig mindent megtud, amire szüksége van.
A OpenVPN közösség ezt kifejezetten dokumentálja: a auth-user-pass-verify átadja a benyújtott hitelesítő adatokat egy ellenőrző szkriptnek vagy bővítménynek. Ez szándékos átadás a komponensek között, és megnevezett félként beletartozik a bizalmi modellbe.
A hitelesítő látja a jelszót
Amint egy komponens jelszót kap az ellenőrzéshez, hozzáférés-vezérlése, naplózása és kódminősége dönti el, hogy a titok bezárva marad-e. Egy szkript, amely a hitelesítő adatokat naplóba írja, vagy egy bővítmény, amely gyorsítótárazza, sokkal nagyobb kitettséget teremt, mint a protokoll. A hozzáférés az architektúrától és a szerepköröktől függ, nem az alagúttól, ezért az ellenőrzőt irányító szolgáltatástulajdonos beletartozik az értékelésbe.
A különböző módszerek különböző anyagokat tárnak fel. A tanúsítványos hitelesítés privát kulcsot bizonyít anélkül, hogy elküldené, és a föderációs folyamat a jelszót az identitásszolgáltatónál tarthatja, miközben korlátozott állítást bocsát ki a VPN felé. Ezek a tervek szűkítik a kört; egyik sem szüntet meg minden megbízható felet.
A tárolt hash-ek egy másik szakaszt védenek
A NIST útmutatása elválasztja a védett átvitelt a hitelesítő ellenálló tárolásától. A sózás és egy költséges hash-séma a tárolt hitelesítő fenyegetését kezeli, ami utólag történik, ha egy adatbázis kiszivárog. Semmit sem tesznek egy futásidejű komponensért, amelynek meg kell kapnia a bemenetet az összehasonlításhoz. Az útmutatást úgy olvasni, mintha futásidejű titoktartást ígérne, kategóriahiba.
Ezért egy jól hashelt jelszótároló és egy nyilvános ellenőrző szkript ellentmondás nélkül együtt létezhet egy termékben.
Olyan módszer választása, amely szűkíti a kört
Ha az a követelmény, hogy az átjáró soha ne kapjon újrahasznosítható jelszót, válasszon olyan módszert, amely ezt valóban garantálja; egy adatrejtjel cseréje nem hozza létre ezt a tulajdonságot. A VPN-kiszolgáló tanúsítványának ellenőrzése megmondja, melyik partnerhez ért el; semmit sem mond arról, hogy az a partner később hogyan kezeli a hitelesítő adatokat. Tartsa meg a kiszolgáló-ellenőrzést, használjon szolgáltatásonként külön hitelesítő adatokat, és kövesse a szervezet által támogatott identitásfolyamatot.
Jegyezze fel a jelszót fogadó felet, az azt ellenőrző felet és azt a formát, amelyben megőrzik. Ez a három válasz a kapcsolati profil mellé tartozik, mert túlélnek minden konkrét alagutat.
A hasznos kérdés nem az, hogy a jelszó titkosított-e, hanem hogy ki elől rejtik el, melyik komponens kapja meg, és milyen forma marad fenn utána.