Először az EAP-módszer: milyen jelszó-hash-t használhat egy VPN
A VPN a titkot ellenőrzi, nem a webes hash-t. Olvassa el a módszert, majd nézze meg, mit tárol a tárhely, mielőtt megígéri, hogy ugyanazok a jelszavak továbbra is működnek.
Sok csapatnak van működő webes bejelentkezése és olyan VPN-je, amely ugyanabból a táblából minden jelszót elutasít. A webalkalmazás egy általa kiszámított hash-t hasonlít össze, míg az alagút arra kéri a klienst, hogy olyan módon bizonyítsa egy titok birtoklását, ahogyan a kiszolgálónak ellenőriznie kell tudnia. Ezek eltérő követelmények a tárolt anyaggal szemben. Éppen a kettő közötti résben akad el ezeknek a projekteknek a többsége.
Először a módszer, aztán a séma
Jegyezze fel, milyen bizonyítékot követel a választott módszer, mielőtt bármilyen sémára pillantana. A kihívás-válasz módszernek olyan anyagra van szüksége, amelyből a kiszolgáló kiszámíthatja az elvárt választ, ami a gyakorlatban a jelszót vagy egy kompatibilis származtatott alakot jelenti. Az a módszer, amely a jelszót védett alagúton belül szállítja, magát a jelszót igényli az ellenőrzőnél. A módszer dokumentációját az ellenőrző követelménye miatt olvassa, ne a kliens konfigurációja miatt, mert a kliens követelményei általában a könnyű rész.
A modern webes keretrendszer által előállított sózott hash egyiket sem nyújtja. Egyetlen konkrét összehasonlítást ellenőriz, és nem fordítható vissza a titokba, amelyből származott.
A kihívás-válasz nem használhat sózott hash-t
Az MSCHAPv2 kihívás-válasz csere, ezért a kiszolgáló soha nem kapja meg a jelszót, és nem tud összehasonlítani egy tárolt karakterláncot. Az elvárt választ az általa már birtokolt anyagból kell levezetnie, és ezért olyan szűkek a kompatibilis tárolt alakok. Egy felhasználónkénti sóval ellátott bcrypt vagy Argon2 érték olyan módon egyirányú, hogy teljesen kizárja a cserét. Az alábbi táblázat a tárolási alakból indul ki, nem a módszer nevéből, mert a tárolási alak dönti el a választ.
| 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 |
Az SQL-bővítmény dokumentációja a strongSwanhoz saját sémát határoz meg a konfigurációhoz és a hitelesítő adatokhoz, és a projekt továbbra is kísérletinek jelöli ezt a bővítményt. Semmi benne nem alkalmazkodik egy alkalmazás felhasználói táblájához, és nem találgatja, melyik hash-elési séma állította elő a tárolt értéket. A reális lehetőségek ezért az átállás egy olyan tárhelyre, amelyet az átjáró használhat, vagy egy hitelesítési szolgáltatás a meglévő tárhely előtt, amely el tudja végezni a cserét. Minden más olyan csatlakozó, amelynek rejtett feltevése van a belsejében.
A RADIUS a munkát mozgatja, nem a követelményt
Az EAP delegálása egy RADIUS-kiszolgálónak megváltoztatja, hol történik az ellenőrzés, és általában javítja az auditnyomot. Nem állít vissza jelszót egy egyirányú hash-ből, ezért a hitelesítési szolgáltatásnak továbbra is a lezárt módszerrel kompatibilis anyagra van szüksége. A csapatok ezt azután tudják meg, hogy felépítették a RADIUS-útvonalat, és a másik végén ugyanabba a falba ütköztek.
Ahol a RADIUS-kiszolgáló tud olvasni egy kompatibilis hitelesítő adatot tartalmazó könyvtárat, ott a terv működik, és a VPN-átjáró egyszerű marad. Ahol nem tud, ott az őszinte válasz a regisztráció megváltoztatása, nem egy újabb csatlakozó. A kiépítés és a visszavonás ahhoz tartozik, aki az identitást birtokolja, ezért egy támogatott szinkronizálási folyamat nélküli másolt tábla a hitelesítő adatok második életciklusa, nem egyszeri bejelentkezés. Az első alkalommal csúszik el, amikor valaki csak egy helyen állítja vissza a jelszót, és az elcsúszás csendes addig, amíg a mindkét rendszerben létező fiók mindegyikben másként nem viselkedik.
Korlátozza a könyvtárat olvasó fiókot pontosan erre az olvasásra, és tartsa külön attól a fióktól, amelyet az átjáró a saját konfigurációjához használ. A megosztott adminisztratív fiók a csak olvasható tervet sokkal szélesebb hatókörré változtatja.
Hol kellene laknia a fióknak
Miután az anyag kérdése eldőlt, két architektúra marad. Az átjáró birtokolhat egy kis hitelesítőadat-tárat, amelyet csak ő olvas, vagy delegálhat egy hitelesítési szolgáltatásnak, amely a vállalati könyvtár előtt áll.
Az első könnyebben átgondolható és rosszabb a felhasználónak, akinek második jelszót kell fenntartania. A második egyetlen identitást tart meg, és hozzáad egy függőséget egy szolgáltatástól, amelynek most már futnia kell, mielőtt bárki csatlakozhat. Egyik sem hibás, de a választást az átjáró konfigurációja mellé kell feljegyezni, különben a következő mérnök azt feltételezi, hogy a másikat választották. Bármit is választ, az alábbi két parancs az, amely megmutatja a jelenlegi állapotot, mielőtt megváltoztatná.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsA fiók hitelesítése az engedélyezést sem rendezi. A csoporttagság, az eszköz állapota és a hálózati engedély továbbra is kifejezett leképezést igényel, miután a felhasználó bizonyította az előírt identitást. Az a kapcsolat, amely tökéletesen hitelesít és semmit nem engedélyez, szabályzati eredmény, nem a módszer hibája.