Nejdřív metoda EAP: který hash hesla může VPN použít
VPN ověřuje tajemství, ne webový hash. Přečtěte si metodu a pak zkontrolujte, co úložiště obsahuje, než slíbíte, že stejná hesla budou dál fungovat.
Hodně týmů má webové přihlášení, které funguje, a VPN, která odmítá každé heslo ze stejné tabulky. Webová aplikace porovnává hash, který si sama spočítala, kdežto tunel žádá klienta, aby prokázal držení tajemství způsobem, který server musí umět ověřit. To jsou různé požadavky na uložený materiál. Právě v mezeře mezi nimi se většina takových projektů zasekne.
Nejdřív metoda, potom schéma
Než se podíváte na jakékoli schéma, zapište, jaký důkaz zvolená metoda vyžaduje. Metoda výzva-odpověď potřebuje materiál, ze kterého server dokáže vypočítat očekávanou odpověď, což v praxi znamená heslo nebo kompatibilní odvozenou podobu. Metoda, která nese heslo uvnitř chráněného tunelu, potřebuje samotné heslo u ověřovatele. Čtěte dokumentaci metody kvůli požadavku na ověřovatele, ne kvůli konfiguraci klienta, protože požadavky klienta jsou obvykle ta snadná část.
Solený hash, který vyprodukuje moderní webový framework, nedodá ani jedno. Ověřuje jedno konkrétní porovnání a nelze ho vrátit zpět k tajemství, z něhož vznikl.
Výzva-odpověď nemůže použít solený hash
MSCHAPv2 je výměna výzva-odpověď, takže server nikdy nedostane heslo a nemůže porovnat uložený řetězec. Musí odvodit očekávanou odpověď z materiálu, který už má, a proto jsou kompatibilní uložené podoby tak úzké. Hodnota bcrypt nebo Argon2 se solí na uživatele je jednosměrná způsobem, který výměnu úplně vylučuje. Tabulka níže vychází z podoby uložení, ne z názvu metody, protože o odpovědi rozhoduje podoba uložení.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Dokumentace SQL pluginu pro strongSwan definuje vlastní schéma pro konfiguraci a přihlašovací údaje a projekt tento plugin stále označuje za experimentální. Nic v ní se nepřizpůsobuje tabulce uživatelů aplikace ani nehádá, které schéma hašování vytvořilo uloženou hodnotu. Reálné možnosti jsou proto migrace do úložiště, které brána umí použít, nebo autentizační služba před stávajícím úložištěm, která výměnu provede. Všechno ostatní je konektor se skrytým předpokladem uvnitř.
RADIUS přesouvá práci, ne požadavek
Delegování EAP na server RADIUS mění místo ověření a obvykle zlepšuje auditní stopu. Neobnoví heslo z jednosměrného hashe, takže autentizační služba stále potřebuje materiál kompatibilní s metodou, kterou ukončuje. Týmy to zjistí poté, co postaví cestu přes RADIUS a narazí na stejnou zeď na druhé straně.
Tam, kde server RADIUS umí číst adresář s kompatibilními přihlašovacími údaji, návrh funguje a VPN brána zůstává jednoduchá. Tam, kde ne, je poctivou odpovědí změna registrace, ne další konektor. Zřizování a odvolávání patří tomu, kdo vlastní identitu, takže zkopírovaná tabulka bez podporovaného synchronizačního procesu je druhý životní cyklus údajů, ne jednotné přihlášení. Rozchází se poprvé, když někdo resetuje heslo jen na jednom místě, a rozchod je tichý, dokud se účet existující v obou systémech nezačne v každém chovat jinak.
Omezte účet, který adresář čte, jen na toto čtení a držte ho oddělený od účtu, který brána používá pro vlastní konfiguraci. Sdílený administrativní účet mění návrh pouze pro čtení v mnohem širší poloměr dopadu.
Kde má účet žít
Jakmile je otázka materiálu vyřešena, zůstávají dvě architektury. Brána může vlastnit malé úložiště údajů, které čte jen ona, nebo může delegovat na autentizační službu, která stojí před podnikovým adresářem.
První se snáz promýšlí a je horší pro uživatele, kterému zůstane druhé heslo k údržbě. Druhá zachovává jednu identitu a přidává závislost na službě, která teď musí být dostupná, než se kdokoli připojí. Ani jedna není špatná, ale volbu je třeba zaznamenat vedle konfigurace brány, protože jinak příští inženýr bude předpokládat, že byla zvolena ta druhá. Ať zvolíte cokoli, dva příkazy níže ukazují současný stav před tím, než ho změníte.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsOvěření účtu také neřeší autorizaci. Členství ve skupinách, stav zařízení a síťové oprávnění stále potřebují výslovné mapování poté, co uživatel prokázal požadovanou identitu. Spojení, které se dokonale ověří a nic neautorizuje, je výsledek politiky, ne chyba v metodě.