Najprej metoda EAP: kateri hash gesla lahko uporabi VPN
VPN preverja skrivnost, ne spletnega hasha. Preberite metodo in nato preverite, kaj shranjuje shramba, preden obljubite, da bodo ista gesla še naprej delovala.
Veliko ekip ima delujočo spletno prijavo in VPN, ki zavrne vsako geslo iz iste tabele. Spletna aplikacija primerja hash, ki ga je izračunala sama, medtem ko tunel odjemalca prosi, naj dokaže posedovanje skrivnosti tako, da mora strežnik to znati preveriti. To so različne zahteve glede shranjenega gradiva. Prav v vrzeli med njima se ustavi večina takšnih projektov.
Najprej metoda, nato shema
Zapišite, kakšen dokaz zahteva izbrana metoda, preden pogledate katero koli shemo. Metoda izziva in odgovora potrebuje gradivo, iz katerega lahko strežnik izračuna pričakovani odgovor, kar v praksi pomeni geslo ali združljivo izpeljano obliko. Metoda, ki geslo prenaša znotraj zaščitenega tunela, potrebuje samo geslo pri preveritelju. Berite dokumentacijo metode zaradi zahteve preveritelja in ne zaradi konfiguracije odjemalca, ker so zahteve odjemalca običajno lažji del.
Soleni hash, ki ga ustvari sodoben spletni okvir, ne da nobenega od obeh. Preveri eno samo določeno primerjavo in ga ni mogoče vrniti v skrivnost, iz katere je nastal.
Izziv in odgovor ne moreta uporabiti solenega hasha
MSCHAPv2 je izmenjava izziva in odgovora, zato strežnik nikoli ne prejme gesla in ne more primerjati shranjenega niza. Pričakovani odgovor mora izpeljati iz gradiva, ki ga že ima, zato so združljive shranjene oblike tako ozke. Vrednost bcrypt ali Argon2 s soljo na uporabnika je enosmerna na način, ki izmenjavo povsem izključi. Spodnja tabela izhaja iz oblike shranjevanja in ne iz imena metode, ker o odgovoru odloča oblika shranjevanja.
| 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 |
Dokumentacija vtičnika SQL za strongSwan opredeljuje lastno shemo za konfiguracijo in poverilnice, projekt pa ta vtičnik še vedno označuje kot poskusni. Nič v njej se ne prilagaja tabeli uporabnikov aplikacije niti ne ugiba, katera shema zgoščevanja je ustvarila shranjeno vrednost. Realne možnosti so torej selitev v shrambo, ki jo prehod lahko uporabi, ali storitev preverjanja pristnosti pred obstoječo shrambo, ki lahko izvede izmenjavo. Vse drugo je konektor s skritim predvidevanjem v sebi.
RADIUS premakne delo, ne zahteve
Prenos EAP na strežnik RADIUS spremeni, kje poteka preverjanje, in običajno izboljša revizijsko sled. Gesla ne obnovi iz enosmernega hasha, zato storitev preverjanja pristnosti še vedno potrebuje gradivo, združljivo z metodo, ki jo zaključuje. Ekipe to ugotovijo potem, ko zgradijo pot RADIUS in na drugi strani naletijo na isto steno.
Kjer lahko strežnik RADIUS bere imenik z združljivimi poverilnicami, rešitev deluje in prehod VPN ostane preprost. Kjer ne more, je pošten odgovor sprememba vpisa in ne še en konektor. Zagotavljanje in preklic pripadata tistemu, ki ima identiteto, zato je kopirana tabela brez podprtega postopka sinhronizacije drugi življenjski cikel poverilnic in ne enotna prijava. Prvič se razhaja, ko nekdo ponastavi geslo samo na enem mestu, in razhajanje je tiho, dokler se račun, ki obstaja v obeh sistemih, v vsakem ne začne obnašati drugače.
Račun, ki bere imenik, omejite natanko na to branje in ga imejte ločeno od računa, ki ga prehod uporablja za lastno konfiguracijo. Skupni skrbniški račun spremeni zasnovo samo za branje v veliko širši polmer vpliva.
Kje naj bi živel račun
Ko je vprašanje gradiva rešeno, ostaneta dve arhitekturi. Prehod ima lahko majhno shrambo poverilnic, ki jo bere samo on, ali pa jo zaupa storitvi preverjanja pristnosti, ki stoji pred poslovnim imenikom.
Prva je lažja za razmislek in slabša za uporabnika, ki mu ostane drugo geslo za vzdrževanje. Druga ohrani eno identiteto in doda odvisnost od storitve, ki mora biti zdaj delujoča, preden se lahko kdo poveže. Nobena ni napačna, a izbiro bi kazalo zapisati ob konfiguraciji prehoda, sicer bo naslednji inženir domneval, da je bila izbrana druga. Karkoli izberete, spodnja dva ukaza sta tista, ki pokažeta trenutno stanje, preden ga spremenite.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsPreverjanje pristnosti računa tudi ne reši pooblastil. Članstvo v skupini, stanje naprave in omrežno dovoljenje še vedno potrebujejo izrecno preslikavo, potem ko je uporabnik dokazal zahtevano identiteto. Povezava, ki se brezhibno preveri in ničesar ne pooblasti, je rezultat politike, ne napaka v metodi.