Erst die EAP-Methode: Welcher Passwort-Hash für eine VPN taugt
Eine VPN prüft das Geheimnis, nicht den Web-Hash. Lesen Sie die Methode und prüfen Sie dann, was der Speicher enthält, bevor Sie versprechen, dass dieselben Passwörter weiter funktionieren.
Viele Teams haben einen Web-Login, der funktioniert, und eine VPN, die jedes Passwort aus derselben Tabelle ablehnt. Die Webanwendung vergleicht einen Hash, den sie selbst berechnet hat, während der Tunnel den Client auffordert, den Besitz eines Geheimnisses so nachzuweisen, dass der Server es prüfen kann. Das sind unterschiedliche Anforderungen an das gespeicherte Material. Genau in dieser Lücke bleiben die meisten dieser Projekte stecken.
Erst die Methode, dann das Schema
Notieren Sie, welchen Nachweis die gewählte Methode verlangt, bevor Sie ein Schema ansehen. Eine Challenge-Response-Methode braucht Material, aus dem der Server die erwartete Antwort berechnen kann, was praktisch das Passwort oder eine kompatible abgeleitete Form bedeutet. Eine Methode, die das Passwort in einem geschützten Tunnel transportiert, braucht das Passwort selbst beim Prüfer. Lesen Sie die Methodendokumentation wegen der Anforderung an den Prüfer und nicht wegen der Clientkonfiguration, denn die Clientanforderungen sind meist der leichte Teil.
Ein gesalzener Hash aus einem modernen Web-Framework liefert weder das eine noch das andere. Er prüft einen bestimmten Vergleich und lässt sich nicht in das Geheimnis zurückführen, aus dem er entstanden ist.
Challenge-Response kann keinen gesalzenen Hash verwenden
MSCHAPv2 ist ein Challenge-Response-Austausch, daher erhält der Server das Passwort nie und kann keine gespeicherte Zeichenkette vergleichen. Er muss die erwartete Antwort aus Material ableiten, das er bereits besitzt, und deshalb sind die kompatiblen Speicherformen so eng. Ein bcrypt- oder Argon2-Wert mit einem Salt pro Benutzer ist so einseitig, dass der Austausch völlig ausscheidet. Die folgende Tabelle geht von der Speicherform aus und nicht vom Methodennamen, weil die Speicherform über die Antwort entscheidet.
| 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 |
Die Dokumentation des SQL-Plugins für strongSwan definiert ein eigenes Schema für Konfiguration und Anmeldedaten, und das Projekt kennzeichnet dieses Plugin weiterhin als experimentell. Nichts darin passt sich der Benutzertabelle einer Anwendung an oder errät, welches Hashverfahren einen gespeicherten Wert erzeugt hat. Die realistischen Optionen sind daher eine Migration auf einen Speicher, den das Gateway nutzen kann, oder ein Authentifizierungsdienst vor dem bestehenden Speicher, der den Austausch durchführen kann. Alles andere ist ein Konnektor mit einer versteckten Annahme darin.
RADIUS verschiebt die Arbeit, nicht die Anforderung
EAP an einen RADIUS-Server zu delegieren ändert, wo die Prüfung stattfindet, und verbessert meist die Prüfspur. Es gewinnt kein Passwort aus einem Einweg-Hash zurück, daher braucht der Authentifizierungsdienst weiterhin Material, das zu der Methode passt, die er terminiert. Teams erfahren das, nachdem sie den RADIUS-Weg gebaut haben und am anderen Ende auf dieselbe Wand treffen.
Wo der RADIUS-Server ein Verzeichnis mit passenden Anmeldedaten lesen kann, funktioniert das Design und das VPN-Gateway bleibt einfach. Wo er es nicht kann, ist die ehrliche Antwort eine Änderung der Registrierung statt eines weiteren Konnektors. Bereitstellung und Widerruf gehören dem, der die Identität besitzt, also ist eine kopierte Tabelle ohne unterstützten Abgleichvorgang ein zweiter Lebenszyklus von Anmeldedaten statt einmaliger Anmeldung. Sie läuft auseinander, sobald jemand ein Passwort nur an einer Stelle zurücksetzt, und das Auseinanderlaufen bleibt still, bis sich ein Konto, das in beiden Systemen existiert, in jedem anders verhält.
Beschränken Sie das Konto, das das Verzeichnis liest, auf genau dieses Lesen und halten Sie es getrennt von dem Konto, das das Gateway für seine eigene Konfiguration nutzt. Ein gemeinsames Administratorkonto macht aus einem Nur-Lese-Design einen deutlich größeren Wirkungsradius.
Wo das Konto liegen sollte
Sobald die Materialfrage geklärt ist, bleiben zwei Architekturen. Das Gateway kann einen kleinen Anmeldedatenspeicher besitzen, den nur es liest, oder an einen Authentifizierungsdienst delegieren, der vor dem Unternehmensverzeichnis steht.
Die erste ist leichter zu durchdenken und schlechter für den Benutzer, der am Ende ein zweites Passwort pflegen muss. Die zweite behält eine Identität und fügt eine Abhängigkeit von einem Dienst hinzu, der nun laufen muss, bevor sich jemand verbinden kann. Keine ist falsch, aber die Wahl sollte neben der Gatewaykonfiguration festgehalten werden, weil der nächste Ingenieur sonst annimmt, es sei die andere geworden. Was immer Sie wählen, die beiden Befehle unten zeigen den aktuellen Stand, bevor Sie ihn ändern.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsKontoauthentifizierung klärt auch die Autorisierung nicht. Gruppenmitgliedschaft, Gerätezustand und Netzwerkberechtigung brauchen weiterhin eine ausdrückliche Zuordnung, nachdem der Benutzer die geforderte Identität nachgewiesen hat. Eine Verbindung, die perfekt authentifiziert und nichts autorisiert, ist ein Richtlinienergebnis und kein Fehler der Methode.