Jūsų VPN slaptažodis tiek privatus, kiek jo tikrintojas

Apsvarstykite keturis klausimus apie bet kokį VPN prisijungimą: kas apsaugo slaptažodį perdavimo metu, kuris komponentas jį gauna, ką tas komponentas su juo daro ir kas saugoma vėliau. Kiekvienas atsakymas yra skirtinga kontrolė, o tvirtas atsakymas į vieną nieko nesako apie kitus. Klaida yra elgtis su tunelio šifravimu taip, tarsi jis apimtų visus keturis. Jis apima pirmąjį, ir tik pirmąjį.

Klauskite, kas užbaigia sesiją, o ne ar sesija užšifruota.

Užšifruota kam, tiksliai?

TLS apsaugo slaptažodį tarp kliento ir to, kas užbaigia ryšį. Jei tas galinis taškas yra VPN šliuzas, šliuzo autentifikavimo kodas mato slaptažodį atviru tekstu, patikrina jį ir perduoda toliau jį arba išvestinę reikšmę. Tai numatytoji konstrukcija, o ne nuotėkis. Tinklo stebėtojas kelyje nesužino nieko naudingo, o tikrinimą atliekantis komponentas sužino viską, ko jam reikia.

OpenVPN bendruomenė tai aiškiai dokumentuoja: auth-user-pass-verify perduoda pateiktus prisijungimo duomenis tikrinimo scenarijui ar papildiniui. Tai tyčinis perdavimas tarp komponentų, ir jis priklauso pasitikėjimo modeliui kaip įvardyta šalis.

Tikrintojas mato slaptažodį

Kai komponentas gauna slaptažodį jam patikrinti, jo prieigos kontrolė, žurnalų rašymas ir kodo kokybė lemia, ar paslaptis lieka uždaryta. Scenarijus, kuris įrašo prisijungimo duomenis į žurnalą, ar papildinys, kuris juos saugo podėlyje, sukuria daug didesnį atskleidimą nei protokolas. Prieiga priklauso nuo architektūros ir vaidmenų, o ne nuo tunelio, todėl paslaugos savininkas, valdantis tikrintoją, priklauso vertinimui.

Skirtingi metodai atskleidžia skirtingą medžiagą. Autentifikavimas sertifikatu įrodo privatų raktą jo nesiunčiant, o federacijos srautas gali palikti slaptažodį tapatybės teikėjui ir išduoti VPN ribotą teiginį. Tos konstrukcijos susiaurina ratą; nė viena jų nepašalina visų patikimų šalių.

Saugomi maišos kodai apsaugo kitą etapą

NIST gairės atskiria apsaugotą perdavimą nuo atsparaus tikrintojo saugojimo. Druska ir brangiai kainuojanti maišos schema sprendžia saugomo tikrintojo grėsmę, tai yra tai, kas nutinka vėliau, jei duomenų bazė nutekėtų. Jos nieko nedaro vykdymo laiko komponentui, kuris turi gauti įvestį, kad ją palygintų. Gaires skaityti taip, tarsi jos žadėtų vykdymo laiko slaptumą, yra kategorijos klaida.

Todėl gerai maišos kodu saugoma slaptažodžių saugykla ir atviras tikrinimo scenarijus gali be prieštaravimų egzistuoti viename produkte.

Metodo, kuris susiaurina ratą, pasirinkimas

Jei reikalavimas yra, kad šliuzas niekada negautų daugkartinio slaptažodžio, pasirinkite metodą, kuris tai tikrai garantuoja; duomenų šifro pakeitimas šios savybės nesukuria. VPN serverio sertifikato tikrinimas pasako, kurį partnerį pasiekėte; jis nieko nesako apie tai, kaip tas partneris vėliau elgiasi su prisijungimo duomenimis. Išsaugokite serverio tikrinimą, naudokite atskirus duomenis kiekvienai paslaugai ir laikykitės organizacijos palaikomo tapatybės srauto.

Užrašykite šalį, kuri gauna slaptažodį, šalį, kuri jį patikrina, ir formą, kuria jis saugomas. Tie trys atsakymai priklauso prie ryšio profilio, nes jie išgyvena kiekvieną konkretų tunelį.

Naudingas klausimas yra ne tai, ar slaptažodis užšifruotas, bet nuo ko jis slepiamas, kuris komponentas jį gauna ir kokia forma išlieka vėliau.