Via VPN-pasvorto estas same privata kiel ĝia kontrolanto
Tunela ĉifrado kovras nur la transdantan parton. La komponanto, kiu kontrolas la pasvorton, ankoraŭ ricevas ĝin, kaj konservita haketaĵo tute protektas pli postan etapon.
Trairu kvar demandojn pri iu ajn VPN-ensaluto: kio protektas la pasvorton dum transporto, kiu komponanto ricevas ĝin, kion tiu komponanto faras kun ĝi, kaj kio estas konservata poste. Ĉiu respondo estas malsama kontrolo, kaj forta respondo pri unu diras nenion pri la aliaj. La eraro estas trakti tunelan ĉifradon kvazaŭ ĝi kovrus ĉiujn kvar. Ĝi kovras la unuan, kaj nur la unuan.
Demandu, kiu finas la seancon, anstataŭ ĉu la seanco estas ĉifrita.
Ĉifrita por kiu, precize?
TLS protektas la pasvorton inter la kliento kaj tio, kio finas la konekton. Se tiu finpunkto estas la VPN-enirejo, la aŭtentiga kodo de la enirejo vidas la pasvorton en klara teksto, validigas ĝin, kaj transdonas plu ĝin aŭ derivitan valoron. Tio estas la intencita dezajno, ne liko. Retobservanto sur la vojo lernas nenion utilan, kaj la komponanto, kiu faras la kontrolon, lernas ĉion, kion ĝi bezonas.
La OpenVPN-komunumo dokumentas tion eksplicite: auth-user-pass-verify transdonas la prezentitajn akreditaĵojn al kontrola skripto aŭ kromaĵo. Ĝi estas intenca transdono inter komponantoj, kaj ĝi apartenas al la fida modelo kiel nomita partio.
La kontrolanto vidas la pasvorton
Post kiam komponanto ricevas pasvorton por kontroli ĝin, ĝiaj alirkontroloj, protokolado kaj kodkvalito decidas, ĉu la sekreto restas enfermita. Skripto, kiu skribas la akreditaĵon en protokolon, aŭ kromaĵo, kiu kaŝmemorigas ĝin, kreas multe pli grandan elmeton ol la protokolo. Aliro dependas de arkitekturo kaj roloj, ne de la tunelo, tial servposedanto, kiu kontrolas la kontrolanton, apartenas al la takso.
Malsamaj metodoj elmontras malsaman materialon. Atestila aŭtentigo pruvas privatan ŝlosilon sen sendi ĝin, kaj federacia fluo povas teni la pasvorton ĉe la identeca provizanto dum ĝi eldonas limigitan aserton al la VPN. Tiuj dezajnoj mallarĝigas la cirklon; neniu el ili forigas ĉiun fidata partion.
Konservitaj haketaĵoj protektas malsaman etapon
La gvidlinioj de NIST apartigas protektitan transdonon de rezistema konservado de la kontrolanto. Salado kaj kosta haketa skemo traktas la minacon de konservita kontrolanto, kio estas tio, kio okazas poste, se datumbazo likas. Ili faras nenion pri rultempa komponanto, kiu devas ricevi la enigon por kompari ĝin. Legi la gvidliniojn kvazaŭ ili promesus rultempan sekretecon estas kategoria eraro.
Bone haketita pasvorta konservejo kaj elmetita kontrola skripto do povas kunekzisti en unu produkto sen kontraŭdiro.
Elekti metodon, kiu mallarĝigas la cirklon
Se la postulo estas, ke la enirejo neniam ricevu reuzeblan pasvorton, elektu metodon, kiu efektive garantias tion; ŝanĝi datuman ĉifron ne kreas tiun econ. Kontroli la atestilon de la VPN-servilo diras al vi, kiun samtavolan partneron vi atingis; ĝi diras nenion pri tio, kiel tiu partnero poste traktas akreditaĵojn. Konservu la servilan kontrolon, uzu apartajn akreditaĵojn por ĉiu servo, kaj sekvu la subtenatan identecan fluon de la organizo.
Registru la partion, kiu ricevas la pasvorton, la partion, kiu validigas ĝin, kaj la formon, en kiu ĝi estas konservata. Tiuj tri respondoj apartenas apud la konekta profilo, ĉar ili postvivas ĉiun apartan tunnelon.
La utila demando ne estas, ĉu la pasvorto estas ĉifrita, sed de kiu ĝi estas kaŝita, kiu komponanto ricevas ĝin, kaj kia formo postvivas.