Eerst de EAP-methode: welke wachtwoordhash een VPN kan gebruiken
Een VPN verifieert het geheim, niet de webhash. Lees de methode en controleer daarna wat de opslag bevat voordat je belooft dat dezelfde wachtwoorden blijven werken.
Veel teams hebben een weblogin dat werkt en een VPN die elk wachtwoord uit dezelfde tabel weigert. De webapplicatie vergelijkt een hash die ze zelf heeft berekend, terwijl de tunnel de client vraagt het bezit van een geheim aan te tonen op een manier die de server moet kunnen controleren. Dat zijn verschillende eisen aan het opgeslagen materiaal. Juist in de kloof daartussen blijven de meeste van deze projecten steken.
Lees eerst de methode, dan het schema
Noteer welk bewijs de gekozen methode vereist voordat je naar enig schema kijkt. Een challenge-responsemethode heeft materiaal nodig waaruit de server het verwachte antwoord kan berekenen, wat in de praktijk het wachtwoord of een compatibele afgeleide vorm betekent. Een methode die het wachtwoord in een beschermde tunnel vervoert, heeft het wachtwoord zelf bij de verifier nodig. Lees de documentatie van de methode voor de eis van de verifier en niet voor de clientconfiguratie, want de cliënteisen zijn meestal het makkelijke deel.
Een gezouten hash van een modern webframework levert geen van beide. Hij verifieert één specifieke vergelijking en kan niet worden teruggevoerd naar het geheim waaruit hij kwam.
Challenge-respons kan geen gezouten hash gebruiken
MSCHAPv2 is een challenge-response-uitwisseling, dus de server ontvangt nooit het wachtwoord en kan geen opgeslagen tekenreeks vergelijken. Hij moet het verwachte antwoord afleiden uit materiaal dat hij al heeft, en daarom zijn de compatibele opgeslagen vormen zo smal. Een bcrypt- of Argon2-waarde met een salt per gebruiker is eenrichtingsverkeer op een manier die de uitwisseling volledig uitsluit. De tabel hieronder begint bij de opslagvorm en niet bij de naam van de methode, omdat de opslagvorm bepaalt wat het antwoord is.
| 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 |
De documentatie van de SQL-plug-in voor strongSwan definieert een eigen schema voor configuratie en inloggegevens, en het project markeert die plug-in nog steeds als experimenteel. Niets erin past zich aan de gebruikers tabel van een applicatie aan of raadt welk hashschema een opgeslagen waarde heeft gemaakt. De realistische opties zijn daarom migratie naar een opslag die de gateway kan gebruiken, of een authenticatiedienst vóór de bestaande opslag die de uitwisseling kan uitvoeren. Al het andere is een connector met een verborgen aanname erin.
RADIUS verplaatst het werk, niet de eis
EAP delegeren aan een RADIUS-server verandert waar de verificatie plaatsvindt en verbetert meestal het auditspoor. Het haalt geen wachtwoord terug uit een eenrichtingshash, dus de authenticatiedienst heeft nog steeds materiaal nodig dat compatibel is met de methode die hij beëindigt. Teams ontdekken dit nadat ze het RADIUS-pad hebben gebouwd en aan de andere kant dezelfde muur tegenkomen.
Waar de RADIUS-server een directory kan lezen met compatibele inloggegevens, werkt het ontwerp en blijft de VPN-gateway eenvoudig. Waar dat niet kan, is het eerlijke antwoord een wijziging in de registratie en niet nog een connector. Inrichting en intrekking horen bij wie de identiteit bezit, dus een gekopieerde tabel zonder ondersteund synchronisatieproces is een tweede levenscyclus van inloggegevens en niet eenmalige aanmelding. Hij loopt uit elkaar de eerste keer dat iemand een wachtwoord op één plek reset, en de drift blijft stil tot een account dat in beide systemen bestaat zich in elk anders gedraagt.
Beperk het account dat de directory leest tot precies dat lezen, en houd het gescheiden van het account dat de gateway voor zijn eigen configuratie gebruikt. Een gedeeld administratief account maakt van een alleen-lezen ontwerp een veel grotere impactradius.
Waar het account moet wonen
Zodra de materiaalkwestie is beslecht, blijven er twee architecturen over. De gateway kan een kleine opslag voor inloggegevens bezitten die alleen hij leest, of delegeren aan een authenticatiedienst die voor de bedrijfsdirectory staat.
De eerste is makkelijker te doordenken en slechter voor de gebruiker, die met een tweede wachtwoord blijft zitten. De tweede houdt één identiteit en voegt een afhankelijkheid toe van een dienst die nu actief moet zijn voordat iemand kan verbinden. Geen van beide is fout, maar de keuze zou naast de gatewayconfiguratie moeten worden vastgelegd, omdat de volgende engineer anders aanneemt dat de andere is gekozen. Wat je ook kiest, de twee opdrachten hieronder zijn degene die de huidige toestand tonen voordat je die wijzigt.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsAccountauthenticatie beslecht de autorisatie ook niet. Groepslidmaatschap, apparaatstatus en netwerktoestemming vragen nog steeds een expliciete koppeling nadat de gebruiker de vereiste identiteit heeft bewezen. Een verbinding die perfect authenticeert en niets autoriseert, is een beleidsresultaat en geen fout in de methode.