EAP-metoden först: vilken lösenordshash en VPN kan använda
En VPN verifierar hemligheten, inte webhashningen. Läs metoden och kontrollera sedan vad lagret innehåller innan du lovar att samma lösenord fortsätter att fungera.
Många team har en webbinloggning som fungerar och en VPN som avvisar varje lösenord från samma tabell. Webbapplikationen jämför en hash som den har beräknat själv, medan tunneln ber klienten bevisa innehav av en hemlighet på ett sätt som servern måste kunna kontrollera. Det är olika krav på det lagrade materialet. Det är i gapet mellan dem som de flesta av dessa projekt fastnar.
Läs metoden, sedan schemat
Skriv ned vilket bevis den valda metoden kräver innan du tittar på något schema. En utmaning-svar-metod behöver material som servern kan beräkna det förväntade svaret från, vilket i praktiken betyder lösenordet eller en kompatibel härledd form. En metod som bär lösenordet inuti en skyddad tunnel behöver själva lösenordet hos verifieraren. Läs metodens dokumentation för verifierarens krav och inte för klientkonfigurationen, eftersom klientkraven oftast är den enkla delen.
En saltad hash från ett modernt webbramverk ger inget av de två. Den verifierar en specifik jämförelse och kan inte föras tillbaka till hemligheten den kom ifrån.
Utmaning-svar kan inte använda en saltad hash
MSCHAPv2 är ett utmaning-svar-utbyte, så servern tar aldrig emot lösenordet och kan inte jämföra en lagrad sträng. Den måste härleda det förväntade svaret från material den redan har, och därför är de kompatibla lagrade formerna så smala. Ett bcrypt- eller Argon2-värde med salt per användare är enkelriktat på ett sätt som utesluter utbytet helt. Tabellen nedan utgår från lagringsformen och inte metodnamnet, eftersom lagringsformen är det som avgö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 |
Dokumentationen för SQL-tillägget till strongSwan definierar ett eget schema för konfiguration och inloggningsuppgifter, och projektet markerar fortfarande tillägget som experimentellt. Inget i den anpassar sig till en applikations användartabell eller gissar vilket hashupplägg som producerade ett lagrat värde. De realistiska alternativen är därför migrering till ett lager som gatewayen kan använda, eller en autentiseringstjänst framför det befintliga lagret som kan utföra utbytet. Allt annat är en koppling med ett dolt antagande inuti.
RADIUS flyttar arbetet, inte kravet
Att delegera EAP till en RADIUS-server ändrar var verifieringen sker och förbättrar oftast revisionsspåret. Det återställer inte ett lösenord från en enkelriktad hash, så autentiseringstjänsten behöver fortfarande material som är kompatibelt med metoden den avslutar. Team upptäcker detta efter att ha byggt RADIUS-vägen och mött samma vägg i andra änden.
Där RADIUS-servern kan läsa en katalog med kompatibla inloggningsuppgifter fungerar designen och VPN-gatewayen förblir enkel. Där den inte kan är det ärliga svaret en ändring i registreringen och inte ännu en koppling. Etablering och återkallande tillhör den som äger identiteten, så en kopierad tabell utan en stödd synkroniseringsprocess är en andra livscykel för inloggningsuppgifter och inte en enda inloggning. Den glider isär första gången någon återställer ett lösenord på bara ett ställe, och glidningen är tyst tills ett konto som finns i båda systemen beter sig olika i vart och ett.
Begränsa kontot som läser katalogen till just den läsningen och håll det åtskilt från kontot som gatewayen använder för sin egen konfiguration. Ett delat administrativt konto gör en skrivskyddad design till en mycket större skadradie.
Var kontot bör bo
När materialfrågan är avgjord återstår två arkitekturer. Gatewayen kan äga ett litet lager för inloggningsuppgifter som bara den läser, eller delegera till en autentiseringstjänst som står framför företagets katalog.
Den första är lättare att tänka igenom och sämre för användaren, som hamnar med ett andra lösenord att underhålla. Den andra behåller en identitet och lägger till ett beroende av en tjänst som nu måste vara igång innan någon kan ansluta. Ingen av dem är fel, men valet bör antecknas bredvid gatewaykonfigurationen, eftersom nästa ingenjör annars antar att den andra valdes. Vad du än väljer är de två kommandona nedan de som visar aktuellt läge innan du ändrar det.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsKontoautentisering avgör inte heller behörigheten. Gruppmedlemskap, enhetsstatus och nätverkstillstånd behöver fortfarande en explicit mappning när användaren har bevisat den krävda identiteten. En anslutning som autentiseras perfekt och inte ger någon behörighet är ett policyresultat, inte ett fel i metoden.