Najprv metóda EAP: ktorý hash hesla môže VPN použiť
VPN overuje tajomstvo, nie webový hash. Prečítajte si metódu a potom skontrolujte, čo úložisko obsahuje, skôr než sľúbite, že tie isté heslá budú fungovať ďalej.
Veľa tímov má fungujúce webové prihlásenie a VPN, ktorá odmieta každé heslo z tej istej tabuľky. Webová aplikácia porovnáva hash, ktorý si sama vypočítala, kým tunel žiada klienta preukázať držanie tajomstva spôsobom, ktorý server musí vedieť overiť. To sú rozdielne požiadavky na uložený materiál. Práve v medzere medzi nimi sa väčšina takýchto projektov zasekne.
Najprv metóda, potom schéma
Napíšte, aký dôkaz zvolená metóda vyžaduje, skôr než sa pozriete na akúkoľvek schému. Metóda výzvy a odpovede potrebuje materiál, z ktorého server dokáže vypočítať očakávanú odpoveď, čo v praxi znamená heslo alebo kompatibilnú odvodenú formu. Metóda, ktorá prenáša heslo v chránenom tuneli, potrebuje samotné heslo u overovateľa. Čítajte dokumentáciu metódy kvôli požiadavke na overovateľa, nie kvôli konfigurácii klienta, pretože klientske požiadavky sú zvyčajne tá ľahká časť.
Solený hash, ktorý vytvorí moderný webový rámec, neposkytuje ani jedno. Overuje jedno konkrétne porovnanie a nedá sa vrátiť späť k tajomstvu, z ktorého vznikol.
Výzva a odpoveď nemôže použiť solený hash
MSCHAPv2 je výmena výzvy a odpovede, takže server nikdy nedostane heslo a nemôže porovnať uložený reťazec. Musí odvodiť očakávanú odpoveď z materiálu, ktorý už má, a preto sú kompatibilné uložené formy také úzke. Hodnota bcrypt alebo Argon2 so soľou na používateľa je jednosmerná spôsobom, ktorý výmenu úplne vylučuje. Tabuľka nižšie vychádza z formy uloženia, nie z názvu metódy, pretože o odpovedi rozhoduje forma uloženia.
| 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 |
Dokumentácia doplnku SQL pre strongSwan definuje vlastnú schému pre konfiguráciu a prihlasovacie údaje a projekt tento doplnok stále označuje ako experimentálny. Nič v nej sa neprispôsobuje tabuľke používateľov aplikácie ani neháda, ktorá schéma hašovania vytvorila uloženú hodnotu. Reálne možnosti sú preto migrácia do úložiska, ktoré brána dokáže použiť, alebo autentifikačná služba pred existujúcim úložiskom, ktorá dokáže vykonať výmenu. Všetko ostatné je konektor so skrytým predpokladom vnútri.
RADIUS presúva prácu, nie požiadavku
Delegovanie EAP na server RADIUS mení, kde overovanie prebieha, a zvyčajne zlepšuje audítorskú stopu. Neobnoví heslo z jednosmerného hashu, takže autentifikačná služba stále potrebuje materiál kompatibilný s metódou, ktorú ukončuje. Tímy to zistia po tom, čo postavia cestu cez RADIUS a na druhom konci narazia na tú istú stenu.
Tam, kde server RADIUS dokáže čítať adresár s kompatibilnými prihlasovacími údajmi, návrh funguje a VPN brána zostáva jednoduchá. Tam, kde nedokáže, je čestnou odpoveďou zmena registrácie, nie ďalší konektor. Zabezpečenie a odvolanie patria tomu, kto vlastní identitu, takže skopírovaná tabuľka bez podporovaného synchronizačného procesu je druhý životný cyklus prihlasovacích údajov, nie jednotné prihlásenie. Rozchádza sa prvýkrát, keď niekto obnoví heslo len na jednom mieste, a rozchod je tichý, kým sa účet existujúci v oboch systémoch nezačne v každom správať inak.
Obmedzte účet, ktorý číta adresár, len na toto čítanie a držte ho oddelene od účtu, ktorý brána používa na vlastnú konfiguráciu. Zdieľaný administratívny účet mení návrh iba na čítanie na oveľa širší polomer dopadu.
Kde má účet žiť
Keď je otázka materiálu vyriešená, zostávajú dve architektúry. Brána môže vlastniť malé úložisko prihlasovacích údajov, ktoré číta iba ona, alebo delegovať na autentifikačnú službu stojacu pred podnikovým adresárom.
Prvá sa ľahšie premýšľa a je horšia pre používateľa, ktorému zostane druhé heslo na údržbu. Druhá zachováva jednu identitu a pridáva závislosť od služby, ktorá teraz musí byť spustená, kým sa niekto pripojí. Ani jedna nie je nesprávna, ale voľbu treba zapísať vedľa konfigurácie brány, inak bude nasledujúci inžinier predpokladať, že bola zvolená tá druhá. Čokoľvek si vyberiete, dva príkazy nižšie ukazujú súčasný stav pred tým, než ho zmeníte.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsOverovanie účtu tiež nerieši autorizáciu. Členstvo v skupinách, stav zariadenia a sieťové povolenie stále potrebujú výslovné mapovanie po tom, čo používateľ preukázal požadovanú identitu. Spojenie, ktoré sa dokonale overí a nič neautorizuje, je výsledkom politiky, nie chybou v metóde.