Pirmiau EAP metodas: kokį slaptažodžio maišą gali naudoti VPN
VPN tikrina paslaptį, o ne žiniatinklio maišą. Perskaitykite metodą ir tada patikrinkite, ką saugo saugykla, prieš žadėdami, kad tie patys slaptažodžiai veiks toliau.
Daug komandų turi veikiantį žiniatinklio prisijungimą ir VPN, kuri atmeta kiekvieną slaptažodį iš tos pačios lentelės. Žiniatinklio programa lygina maišą, kurį pati apskaičiavo, o tunelis prašo kliento įrodyti paslapties turėjimą taip, kad serveris turėtų galėti tai patikrinti. Tai skirtingi reikalavimai saugomai medžiagai. Būtent šiame tarp jų esančiame atotrūkyje dauguma tokių projektų ir sustoja.
Pirmiausia metodas, paskui schema
Užsirašykite, kokio įrodymo reikalauja pasirinktas metodas, prieš žiūrėdami į bet kokią schemą. Iššūkio ir atsakymo metodui reikia medžiagos, iš kurios serveris gali apskaičiuoti laukiamą atsakymą, o tai praktiškai reiškia slaptažodį arba suderinamą išvestinę formą. Metodui, kuris neša slaptažodį apsaugotame tunelyje, reikia paties slaptažodžio pas tikrintoją. Skaitykite metodo dokumentaciją dėl tikrintojo reikalavimo, o ne dėl kliento konfigūracijos, nes kliento reikalavimai paprastai yra lengvoji dalis.
Šiuolaikinės žiniatinklio sistemos sukuriamas pasūdytas maišas neduoda nė vieno. Jis patikrina vieną konkretų palyginimą ir negali būti grąžintas į paslaptį, iš kurios atsirado.
Iššūkis ir atsakymas negali naudoti pasūdyto maišo
MSCHAPv2 yra iššūkio ir atsakymo mainai, todėl serveris niekada negauna slaptažodžio ir negali palyginti saugomos eilutės. Jis turi išvesti laukiamą atsakymą iš medžiagos, kurią jau turi, ir todėl suderinamos saugomos formos yra tokios siauros. Bcrypt arba Argon2 reikšmė su kiekvienam naudotojui atskira druska yra vienkryptė taip, kad mainai visiškai neįmanomi. Toliau pateikta lentelė pradedama nuo saugojimo formos, o ne nuo metodo pavadinimo, nes būtent saugojimo forma lemia atsakymą.
| 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 |
SQL papildinio dokumentacija skirta strongSwan apibrėžia savo schemą konfigūracijai ir prisijungimo duomenims, o projektas tą papildinį vis dar žymi kaip eksperimentinį. Niekas joje neprisitaiko prie programos naudotojų lentelės ir nespėja, kuri maišos schema sukūrė saugomą reikšmę. Todėl realios galimybės yra migracija į saugyklą, kurią šliuzas gali naudoti, arba autentifikavimo tarnyba prieš esamą saugyklą, galinti atlikti mainus. Visa kita yra jungtis su paslėpta prielaida viduje.
RADIUS perkelia darbą, o ne reikalavimą
EAP delegavimas RADIUS serveriui pakeičia, kur vyksta tikrinimas, ir paprastai pagerina audito pėdsaką. Jis neatgauna slaptažodžio iš vienkryptės maišos, todėl autentifikavimo tarnybai vis dar reikia medžiagos, suderinamos su metodu, kurį ji užbaigia. Komandos tai sužino pastatę RADIUS kelią ir kitame gale atsitrenkę į tą pačią sieną.
Ten, kur RADIUS serveris gali skaityti katalogą su suderinamais prisijungimo duomenimis, sprendimas veikia ir VPN šliuzas lieka paprastas. Ten, kur negali, sąžiningas atsakymas yra registracijos pakeitimas, o ne dar viena jungtis. Teikimas ir atšaukimas priklauso tam, kas valdo tapatybę, todėl nusikopijuota lentelė be palaikomo sinchronizavimo proceso yra antras prisijungimo duomenų gyvavimo ciklas, o ne vienas prisijungimas. Ji pradeda skirtis pirmą kartą, kai kas nors atkuria slaptažodį tik vienoje vietoje, ir tas skirtumas tyliai auga, kol abiejose sistemose esanti paskyra pradeda elgtis skirtingai kiekvienoje.
Apribokite katalogą skaitančią paskyrą vien tik tam skaitymui ir laikykite ją atskirai nuo paskyros, kurią šliuzas naudoja savo konfigūracijai. Bendra administracinė paskyra tik skaitymo sprendimą paverčia daug platesniu poveikio spinduliu.
Kur paskyra turėtų gyventi
Kai medžiagos klausimas išspręstas, lieka dvi architektūros. Šliuzas gali turėti nedidelę prisijungimo duomenų saugyklą, kurią skaito tik jis, arba deleguoti autentifikavimo tarnybai, stovinčiai prieš įmonės katalogą.
Pirmoji lengviau apmąstoma ir prastesnė naudotojui, kuriam lieka prižiūrėti antrą slaptažodį. Antroji išlaiko vieną tapatybę ir prideda priklausomybę nuo tarnybos, kuri dabar turi veikti prieš kam nors prisijungiant. Nė viena nėra klaidinga, bet pasirinkimą reikėtų užrašyti prie šliuzo konfigūracijos, nes kitaip kitas inžinierius manys, kad pasirinkta kita. Kad ir ką pasirinktumėte, dvi žemiau pateiktos komandos parodo dabartinę būseną prieš ją keičiant.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsPaskyros autentifikavimas taip pat neišsprendžia autorizacijos. Grupės narystė, įrenginio būsena ir tinklo leidimas vis dar reikalauja aiškaus susiejimo po to, kai naudotojas įrodė reikiamą tapatybę. Ryšys, kuris puikiai autentifikuojamas ir nieko neautorizuoja, yra politikos rezultatas, o ne metodo trūkumas.