Fyrst EAP-metoden: kva passordhash ein VPN kan bruke
Ein VPN stadfester hemmelegheita, ikkje webhashen. Les metoden og sjekk deretter kva lageret held før du lovar at dei same passorda vil halde fram med å verke.
Mange team har ei webinnlogging som verkar og eit VPN som avviser kvart passord frå den same tabellen. Webapplikasjonen samanliknar ein hash han har rekna ut sjølv, medan tunnelen ber klienten prova at han sit på ei hemmelegheit på ein måte serveren må kunne kontrollere. Dette er ulike krav til materialet som er lagra. I gapet mellom dei stoppar dei fleste slike prosjekt.
Les metoden, deretter skjemaet
Skriv ned kva prov den valde metoden krev før du ser på noko skjema. Ein utfordring-svar-metode treng materiale som serveren kan rekne ut det venta svaret frå, noko som i praksis tyder passordet eller ei kompatibel avleidd form. Ein metode som ber passordet inne i ein verna tunnel treng sjølve passordet hos stadfestaren. Les dokumentasjonen til metoden for kravet til stadfestaren og ikkje for klientkonfigurasjonen, fordi klientkrava vanlegvis er den enkle delen.
Ein salta hash frå eit moderne webrammeverk gjev ingen av delane. Han stadfester éin bestemd samanlikning og kan ikkje førast tilbake til hemmelegheita han kom frå.
Utfordring-svar kan ikkje bruke ein salta hash
MSCHAPv2 er ein utfordring-svar-utveksling, så serveren mottek aldri passordet og kan ikkje samanlikne ein lagra streng. Han må utleie det venta svaret frå materiale han alt har, og difor er dei kompatible lagra formene så smale. Ein bcrypt- eller Argon2-verdi med salt per brukar er einvegskøyrd på ein måte som stengjer utvekslinga heilt ute. Tabellen nedanfor tek utgangspunkt i lagerforma og ikkje metodenamnet, fordi lagerforma er det som avgjer svaret.
| 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 |
Dokumentasjonen for SQL-tillegget til strongSwan definerer sitt eige skjema for konfigurasjon og påloggingsdata, og prosjektet merkjer framleis det tillegget som eksperimentelt. Ingenting i han tilpassar seg brukartabellen til ein applikasjon eller gjetar kva hashing-opplegg som produserte ein lagra verdi. Dei realistiske alternativa er difor migrering til eit lager gatewayen kan bruke, eller ein autentiseringsteneste framfor det eksisterande lageret som kan utføre utvekslinga. Alt anna er ei kopling med ei skjult føresetnad inni seg.
RADIUS flyttar arbeidet, ikkje kravet
Å delegere EAP til ein RADIUS-server endrar kvar stadfestinga skjer og betrar vanlegvis revisjonssporet. Det gjenopprettar ikkje eit passord frå ein einvegshash, så autentiseringstenesta treng framleis materiale som er kompatibelt med metoden ho avsluttar. Team oppdagar dette etter å ha bygd RADIUS-vegen og møtt den same veggen i den andre enden.
Der RADIUS-serveren kan lese ein katalog med kompatible påloggingsdata, verkar designet og VPN-gatewayen held seg enkel. Der han ikkje kan, er det ærlege svaret ei endring i registreringa og ikkje ei ny kopling. Provisjonering og tilbakekalling høyrer til den som eig identiteten, så ein kopiert tabell utan ein støtta synkroniseringsprosess er ein andre livssyklus for påloggingsdata og ikkje éi enkel pålogging. Han driv første gong nokon nullstiller eit passord på berre éin stad, og drifta er stille til ein konto som finst i begge systema oppfører seg ulikt i kvart av dei.
Afgrens kontoen som les katalogen til nettopp den lesinga, og hald han skild frå kontoen gatewayen brukar til sin eigen konfigurasjon. Ein delt administrativ konto gjer eit skriveverna design til ein mykje større skaderadius.
Kvar kontoen bør bu
Når materialspørsmålet er avgjort, står to arkitekturer att. Gatewayen kan eige eit lite lager for påloggingsdata som berre han les, eller delegere til ein autentiseringsteneste som står framfor bedriftskatalogen.
Den første er lettare å tenkje gjennom og dårlegare for brukaren, som endar med eit andre passord å vedlikehalde. Den andre held på éin identitet og legg til ein avhengnad av ei teneste som no må vere oppe før nokon kan kople til. Ingen av dei er feil, men valet bør noterast ved sida av gatewaykonfigurasjonen, fordi den neste ingeniøren elles vil gå ut frå at den andre vart vald. Uansett kva du vel, er dei to kommandoane nedanfor dei som viser gjeldande tilstand før du endrar han.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsKontoautentisering avgjer heller ikkje autorisasjon. Gruppemedlemskap, einingstilstand og nettverkstillating treng framleis ei eksplisitt kopling når brukaren har prova den påkravde identiteten. Ei tilkopling som autentiserer perfekt og ikkje autoriserer noko, er eit policyresultat og ikkje ein feil i metoden.