Mai întâi metoda EAP: ce hash de parolă poate folosi un VPN
Un VPN verifică secretul, nu hash-ul web. Citiți metoda, apoi verificați ce păstrează depozitul înainte de a promite că aceleași parole vor continua să funcționeze.
Multe echipe au o autentificare web care funcționează și un VPN care refuză fiecare parolă din același tabel. Aplicația web compară un hash pe care l-a calculat ea însăși, în timp ce tunelul îi cere clientului să dovedească deținerea unui secret într-un mod pe care serverul trebuie să îl poată verifica. Sunt cerințe diferite asupra materialului stocat. Exact în golul dintre ele se blochează majoritatea acestor proiecte.
Citiți metoda, apoi schema
Notați ce dovadă cere metoda aleasă înainte de a privi orice schemă. O metodă de tip provocare-răspuns are nevoie de material din care serverul poate calcula răspunsul așteptat, ceea ce în practică înseamnă parola sau o formă derivată compatibilă. O metodă care transportă parola într-un tunel protejat are nevoie de parola însăși la verificator. Citiți documentația metodei pentru cerința verificatorului și nu pentru configurația clientului, fiindcă cerințele clientului sunt de obicei partea ușoară.
Un hash cu sare produs de un framework web modern nu oferă niciuna dintre cele două. Verifică o singură comparație anume și nu poate fi readus la secretul din care a provenit.
Provocare-răspuns nu poate folosi un hash cu sare
MSCHAPv2 este un schimb de tip provocare-răspuns, așa că serverul nu primește niciodată parola și nu poate compara un șir stocat. Trebuie să derive răspunsul așteptat din materialul pe care îl deține deja, și de aceea formele stocate compatibile sunt atât de înguste. O valoare bcrypt sau Argon2 cu sare pentru fiecare utilizator este unidirecțională într-un mod care exclude complet schimbul. Tabelul de mai jos pornește de la forma de stocare, nu de la numele metodei, fiindcă forma de stocare este cea care decide răspunsul.
| 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 |
Documentația modulului SQL pentru strongSwan definește o schemă proprie pentru configurație și acreditări, iar proiectul marchează în continuare acel modul drept experimental. Nimic din ea nu se adaptează la tabelul de utilizatori al unei aplicații și nu ghicește ce schemă de hashing a produs o valoare stocată. Opțiunile realiste sunt deci migrarea către un depozit pe care gateway-ul îl poate folosi, sau un serviciu de autentificare în fața depozitului existent care poate efectua schimbul. Orice altceva este un conector cu o presupunere ascunsă în interior.
RADIUS mută munca, nu cerința
Delegarea EAP către un server RADIUS schimbă locul unde are loc verificarea și de obicei îmbunătățește urma de audit. Nu recuperează o parolă dintr-un hash unidirecțional, așa că serviciul de autentificare are în continuare nevoie de material compatibil cu metoda pe care o termină. Echipele află asta după ce construiesc calea RADIUS și întâlnesc același zid la celălalt capăt.
Acolo unde serverul RADIUS poate citi un director cu acreditări compatibile, proiectul funcționează, iar gateway-ul VPN rămâne simplu. Acolo unde nu poate, răspunsul cinstit este o schimbare în înregistrare și nu un alt conector. Aprovizionarea și revocarea aparțin celui care deține identitatea, așa că un tabel copiat fără un proces de sincronizare acceptat este un al doilea ciclu de viață al acreditărilor și nu o autentificare unică. Se desincronizează prima dată când cineva resetează o parolă într-un singur loc, iar deriva este tăcută până când un cont care există în ambele sisteme se comportă diferit în fiecare.
Limitați contul care citește directorul doar la acea citire și țineți-l separat de contul pe care gateway-ul îl folosește pentru propria configurație. Un cont administrativ partajat transformă un proiect doar-citire într-o rază de impact mult mai largă.
Unde ar trebui să locuiască contul
După ce întrebarea despre material este rezolvată, rămân două arhitecturi. Gateway-ul poate deține un mic depozit de acreditări pe care doar el îl citește, sau poate delega către un serviciu de autentificare aflat în fața directorului companiei.
Prima este mai ușor de gândit și mai rea pentru utilizator, care rămâne cu o a doua parolă de întreținut. A doua păstrează o singură identitate și adaugă o dependență de un serviciu care acum trebuie să fie pornit înainte ca cineva să se poată conecta. Niciuna nu este greșită, dar alegerea ar trebui notată lângă configurația gateway-ului, altfel următorul inginer va presupune că a fost aleasă cealaltă. Orice ați alege, cele două comenzi de mai jos sunt cele care arată starea actuală înainte de a o schimba.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsAutentificarea contului nu rezolvă nici autorizarea. Apartenența la grup, starea dispozitivului și permisiunea de rețea au în continuare nevoie de o mapare explicită după ce utilizatorul a dovedit identitatea cerută. O conexiune care se autentifică perfect și nu autorizează nimic este un rezultat de politică, nu un defect al metodei.