Ihr VPN-Passwort ist nur so privat wie sein Prüfer

Gehen Sie vier Fragen zu jedem VPN-Login durch: Was schützt das Passwort bei der Übertragung, welche Komponente empfängt es, was macht diese Komponente damit, und was wird anschließend gespeichert. Jede Antwort ist eine andere Kontrolle, und eine belastbare Antwort auf eine sagt nichts über die anderen. Der Fehler ist, die Tunnelverschlüsselung zu behandeln, als ob sie alle vier abdeckte. Sie deckt die erste ab, und nur die erste.

Fragen Sie, wer die Sitzung beendet, statt ob die Sitzung verschlüsselt ist.

Verschlüsselt gegenüber wem, genau?

TLS schützt das Passwort zwischen dem Client und demjenigen, der die Verbindung beendet. Ist dieser Endpunkt der VPN-Gateway, sieht der Authentifizierungscode des Gateways das Passwort im Klartext, prüft es und gibt es oder einen abgeleiteten Wert weiter. Das ist der beabsichtigte Entwurf, kein Leck. Ein Netzbeobachter auf dem Pfad erfährt nichts Nützliches, und die Komponente, die die Prüfung durchführt, erfährt alles, was sie braucht.

Die OpenVPN-Gemeinschaft dokumentiert dies ausdrücklich: auth-user-pass-verify übergibt die vorgelegten Anmeldedaten an ein Prüfskript oder Plugin. Das ist eine absichtliche Übergabe zwischen Komponenten, und sie gehört als benannte Partei ins Vertrauensmodell.

Der Prüfer sieht das Passwort

Sobald eine Komponente ein Passwort zum Prüfen erhält, entscheiden ihre Zugriffskontrollen, ihre Protokollierung und ihre Codequalität darüber, ob das Geheimnis eingeschlossen bleibt. Ein Skript, das die Anmeldedaten in ein Protokoll schreibt, oder ein Plugin, das sie zwischenspeichert, erzeugt eine weit größere Exposition als das Protokoll. Der Zugriff hängt von Architektur und Rollen ab, nicht vom Tunnel, weshalb ein Dienstverantwortlicher, der den Prüfer kontrolliert, in die Bewertung gehört.

Verschiedene Verfahren legen unterschiedliches Material offen. Die Zertifikatsauthentifizierung weist einen privaten Schlüssel nach, ohne ihn zu senden, und ein Föderationsfluss kann das Passwort beim Identitätsanbieter belassen und dem VPN eine begrenzte Aussage ausstellen. Diese Entwürfe verengen den Kreis; keiner von ihnen beseitigt jede vertrauenswürdige Partei.

Gespeicherte Hashes schützen eine andere Stufe

Die NIST-Leitlinien trennen geschützte Übertragung von widerstandsfähiger Prüfer-Speicherung. Salt und ein kostenintensives Hashverfahren adressieren die Bedrohung durch den gespeicherten Prüfer, also das, was nachträglich geschieht, wenn eine Datenbank abfließt. Gegen eine Laufzeitkomponente, die die Eingabe empfangen muss, um sie zu vergleichen, tun sie nichts. Die Leitlinien zu lesen, als versprächen sie Laufzeitgeheimhaltung, ist ein Kategorienfehler.

Ein gut gehashter Passwortspeicher und ein offengelegtes Prüfskript können daher ohne Widerspruch in einem Produkt koexistieren.

Ein Verfahren wählen, das den Kreis verengt

Wenn die Anforderung lautet, dass der Gateway nie ein wiederverwendbares Passwort erhält, wählen Sie ein Verfahren, das dies tatsächlich garantiert; eine Datenchiffre zu wechseln erzeugt diese Eigenschaft nicht. Das Zertifikat des VPN-Servers zu prüfen sagt Ihnen, welchen Peer Sie erreicht haben; es sagt nichts darüber, wie dieser Peer anschließend mit Anmeldedaten umgeht. Behalten Sie die Serverprüfung bei, verwenden Sie getrennte Anmeldedaten pro Dienst, und folgen Sie dem unterstützten Identitätsfluss der Organisation.

Halten Sie fest, welche Partei das Passwort erhält, welche es prüft und in welcher Form es aufbewahrt wird. Diese drei Antworten gehören neben das Verbindungsprofil, weil sie jeden einzelnen Tunnel überleben.

Die nützliche Frage ist nicht, ob das Passwort verschlüsselt ist, sondern vor wem es verborgen wird, welche Komponente es erhält und welche Form danach überlebt.