Your VPN Password Is Only as Private as Its Verifier
Tunnel encryption covers the transit leg. The component that verifies the password still receives it, and a stored hash protects a later stage entirely.
Work through four questions about any VPN login: what protects the password in transit, which component receives it, what that component does with it, and what gets stored afterwards. Each answer is a different control, and a strong answer to one says nothing about the others. The mistake is to treat tunnel encryption as if it covered all four. It covers the first, and only the first.
Ask who terminates the session rather than whether the session is encrypted.
Encrypted To Whom, Exactly?
TLS protects the password between the client and whatever terminates the connection. If that endpoint is the VPN gateway, the gateway's authentication code sees the plaintext password, validates it, and passes it or a derived value onward. That is the intended design, not a leak. A network observer on the path learns nothing useful, and the component doing the verification learns everything it needs.
Community OpenVPN documents this explicitly: auth-user-pass-verify hands the submitted credentials to a verification script or plugin. It is an intentional handoff between components, and it belongs in the trust model as a named party.
The Verifier Sees the Password
Once a component receives a password to verify it, that component's access controls, logging and code quality decide whether the secret stays contained. A script that writes the credential into a log, or a plugin that caches it, creates a far larger exposure than the protocol did. Access depends on architecture and roles rather than on the tunnel, which is why a service owner controlling the verifier belongs in the assessment.
Different methods expose different material. Certificate authentication proves a private key without sending it, and a federation flow can keep the password at the identity provider while issuing a scoped assertion to the VPN. Those designs narrow the circle; none of them eliminates every trusted party.
Stored Hashes Protect a Different Stage
NIST's guidance separates protected transmission from resistant verifier storage. Salting and a costed hashing scheme address the stored-verifier threat, which is what happens after the fact if a database leaks. They do nothing about a runtime component that must receive the input to compare it. Reading the guidance as if it promised runtime secrecy is a category error.
A well-hashed password store and an exposed verification script can therefore coexist in one product without contradiction.
Choosing a Method That Narrows the Circle
If the requirement is that the gateway never receives a reusable password, pick a method that actually guarantees it; changing a data cipher does not create that property. Verifying the VPN server's certificate tells you which peer you reached; it says nothing about how that peer handles credentials afterwards. Keep server verification, use distinct credentials per service, and follow the organisation's supported identity flow.
Record the party that receives the password, the party that validates it and the form in which it is retained. Those three answers belong beside the connection profile, because they outlive any particular tunnel.
The useful question is not whether the password is encrypted but who it is hidden from, which component receives it, and what form survives afterwards.