Vaše heslo k VPN je soukromé jen tak jako jeho ověřovatel

Projděte čtyři otázky u každého přihlášení k VPN: co chrání heslo při přenosu, která komponenta ho dostává, co s ním tato komponenta dělá a co se potom ukládá. Každá odpověď je jiná kontrola a silná odpověď na jednu neříká nic o ostatních. Chyba je považovat šifrování tunelu za něco, co pokrývá všechny čtyři. Pokrývá první, a jen první.

Ptejte se, kdo ukončuje relaci, ne zda je relace šifrovaná.

Šifrované vůči komu, přesně?

TLS chrání heslo mezi klientem a tím, co ukončuje spojení. Pokud je tím koncovým bodem brána VPN, její autentizační kód vidí heslo v otevřené podobě, ověří ho a předá dál buď je, nebo odvozenou hodnotu. To je zamýšlený návrh, ne únik. Síťový pozorovatel na cestě se nedozví nic užitečného a komponenta provádějící ověření se dozví vše, co potřebuje.

Komunita OpenVPN to výslovně dokumentuje: auth-user-pass-verify předává předložené přihlašovací údaje ověřovacímu skriptu nebo pluginu. Je to záměrné předání mezi komponentami a patří do modelu důvěry jako pojmenovaná strana.

Ověřovatel vidí heslo

Jakmile komponenta dostane heslo k ověření, o tom, zda tajemství zůstane uzavřené, rozhodují její řízení přístupu, logování a kvalita kódu. Skript, který zapíše přihlašovací údaj do logu, nebo plugin, který ho uloží do mezipaměti, vytváří mnohem větší expozici, než vytvořil protokol. Přístup závisí na architektuře a rolích, ne na tunelu, a proto do hodnocení patří vlastník služby, který ověřovatele ovládá.

Různé metody odhalují různý materiál. Autentizace certifikátem prokazuje soukromý klíč, aniž by ho odeslala, a federační tok může ponechat heslo u poskytovatele identity a vydat VPN omezené tvrzení. Tyto návrhy zužují okruh; žádný z nich neodstraňuje všechny důvěryhodné strany.

Uložené hashe chrání jinou fázi

Pokyny NIST oddělují chráněný přenos od odolného uložení ověřovatele. Solení a nákladné hašování řeší hrozbu uloženého ověřovatele, což je to, co se stane dodatečně, pokud unikne databáze. S komponentou za běhu, která musí vstup přijmout, aby ho porovnala, nedělají nic. Číst pokyny, jako by slibovaly tajnost za běhu, je kategorická chyba.

Dobře hašované úložiště hesel a vystavený ověřovací skript tedy mohou v jednom produktu existovat vedle sebe bez rozporu.

Volba metody, která zužuje okruh

Pokud je požadavkem, aby brána nikdy nedostala znovupoužitelné heslo, zvolte metodu, která to skutečně zaručí; změna šifry dat tuto vlastnost nevytváří. Ověření certifikátu serveru VPN vám řekne, ke kterému protějšku jste se dostali; neříká nic o tom, jak tento protějšek potom nakládá s přihlašovacími údaji. Zachovejte ověřování serveru, používejte odlišné údaje pro každou službu a postupujte podle organizací podporovaného toku identity.

Zaznamenejte stranu, která heslo dostává, stranu, která ho ověřuje, a formu, v níž se uchovává. Tyto tři odpovědi patří vedle profilu připojení, protože přežívají každý konkrétní tunel.

Užitečná otázka není, zda je heslo šifrované, ale před kým je skryté, která komponenta ho dostává a jaká forma později přetrvává.