EAP-metoden først: hvilken passordhash en VPN kan bruke
En VPN verifiserer hemmeligheten, ikke webhashen. Les metoden, og sjekk deretter hva lageret inneholder før du lover at de samme passordene vil fortsette å virke.
Mange team har en webinnlogging som virker og en VPN som avviser hvert passord fra den samme tabellen. Webapplikasjonen sammenligner en hash den har beregnet selv, mens tunnelen ber klienten bevise at den besitter en hemmelighet på en måte serveren må kunne kontrollere. Dette er ulike krav til materialet som lagres. Det er i gapet mellom dem de fleste slike prosjekter stopper.
Les metoden, deretter skjemaet
Skriv ned hvilket bevis den valgte metoden krever før du ser på noe skjema. En utfordring-svar-metode trenger materiale som serveren kan beregne det forventede svaret fra, noe som i praksis betyr passordet eller en kompatibel avledet form. En metode som bærer passordet inne i en beskyttet tunnel trenger selve passordet hos verifisereren. Les dokumentasjonen til metoden for kravet til verifisereren og ikke for klientkonfigurasjonen, fordi klientkravene vanligvis er den enkle delen.
En saltet hash fra et moderne webframework gir ingen av delene. Den verifiserer én bestemt sammenligning og kan ikke føres tilbake til hemmeligheten den kom fra.
Utfordring-svar kan ikke bruke en saltet hash
MSCHAPv2 er en utfordring-svar-utveksling, så serveren mottar aldri passordet og kan ikke sammenligne en lagret streng. Den må utlede det forventede svaret fra materiale den allerede har, og derfor er de kompatible lagrede formene så smale. En bcrypt- eller Argon2-verdi med salt per bruker er enveiskjørt på en måte som utelukker utvekslingen helt. Tabellen nedenfor tar utgangspunkt i lagerformen og ikke metodenavnet, fordi lagerformen er det som avgjør 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-pluginen til strongSwan definerer sitt eget skjema for konfigurasjon og påloggingsdata, og prosjektet merker fortsatt den pluginen som eksperimentell. Ingenting i den tilpasser seg brukertabellen til en applikasjon eller gjetter hvilket hashing-opplegg som produserte en lagret verdi. De realistiske alternativene er derfor migrering til et lager gatewayen kan bruke, eller en autentiseringstjeneste foran det eksisterende lageret som kan utføre utvekslingen. Alt annet er en kobling med en skjult forutsetning inni seg.
RADIUS flytter arbeidet, ikke kravet
Å delegere EAP til en RADIUS-server endrer hvor verifiseringen skjer og forbedrer vanligvis revisjonssporet. Det gjenoppretter ikke et passord fra en enveis-hash, så autentiseringstjenesten trenger fortsatt materiale som er kompatibelt med metoden den avslutter. Team oppdager dette etter å ha bygget RADIUS-veien og møtt den samme veggen i den andre enden.
Der RADIUS-serveren kan lese en katalog med kompatible påloggingsdata, fungerer designet og VPN-gatewayen forblir enkel. Der den ikke kan, er det ærlige svaret en endring i registreringen og ikke en ny kobling. Provisjonering og tilbakekalling tilhører den som eier identiteten, så en kopiert tabell uten en støttet synkroniseringsprosess er en andre livssyklus for påloggingsdata og ikke enkelt pålogging. Den driver første gang noen tilbakestiller et passord på bare ett sted, og driften er stille til en konto som finnes i begge systemene oppfører seg forskjellig i hvert av dem.
Begrens kontoen som leser katalogen til nettopp den lesingen, og hold den atskilt fra kontoen gatewayen bruker til sin egen konfigurasjon. En delt administrativ konto gjør et skrivebeskyttet design til en mye større skadradius.
Hvor kontoen bør bo
Når materialspørsmålet er avgjort, står to arkitekturer igjen. Gatewayen kan eie et lite lager for påloggingsdata som bare den leser, eller delegere til en autentiseringstjeneste som står foran bedriftens katalog.
Den første er lettere å tenke gjennom og dårligere for brukeren, som ender med et andre passord å vedlikeholde. Den andre beholder én identitet og legger til en avhengighet til en tjeneste som nå må være oppe før noen kan koble til. Ingen av dem er feil, men valget bør noteres ved siden av gatewaykonfigurasjonen, fordi den neste ingeniøren ellers vil anta at den andre ble valgt. Uansett hva du velger, er de to kommandoene nedenfor de som viser gjeldende tilstand før du endrer den.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsKontoautentisering avgjør heller ikke autorisasjon. Gruppemedlemskap, enhetstilstand og nettverkstillatelse trenger fortsatt en eksplisitt mapping når brukeren har bevist den påkrevde identiteten. En tilkobling som autentiserer perfekt og ikke autoriserer noe, er et policyresultat og ikke en feil i metoden.