Exploiting (or abusing) password fields for Multi-Factor Authentication

March 31, 2023

I've recently been looking into how people add Multi-Factor Authentication (MFA) to their OpenVPN systems, both using commercial solutions and home grown ones. One of the things that makes this difficult is that I believe the OpenVPN authentication protocol is old fashioned enough that it doesn't provide for multi-step interaction. Instead, clients can send either or both of a TLS client certificate and a username plus password pair to the server, and the server gets to decide. However, common OpenVPN server software allows you to plug in your own code to do the user and password authentication, and so it turns out that people have used this to add MFA.

The simpler approach is one taken by a particular commercial MFA vendor I'm not going to name. With them, your OpenVPN server has to require both client certificates and a username and password. Their plugin ignores the username (instead using the TLS client certificate's Common Name) and treats the 'password' as what you'd enter in response to their MFA prompt, which is either a one-time passcode or a MFA authentication method like 'push authenticate with my first registered phone'. Presumably their plugin then waits for the MFA authentication to be approved, denied, or time out before it returns a 'yes/no' answer to OpenVPN.

The more complicated approach I've seen is to embed the MFA answer as part of the 'password' that clients supply. People have a regular username and password, and also an additional MFA authentication with something like TOTP. To authenticate to your OpenVPN, the password you actually send concatenates the two together, for example '<regular password>:<TOTP code>'. The OpenVPN authentication plugin then cracks the password apart and verifies the two pieces separately.

What reading about all of this has made me realize is that any time the client sends a plain text password to the server, it can be exploited to do MFA. Generally you need the server to have some sort of pluggable authentication, but many servers have that, either explicitly or because they use the system authentication methods and those are built on PAM. Now, no one said that this is necessarily the best idea or the best way to implement MFA (and indeed the OpenVPN version comes with some caveats), but you aren't always dealing with an ideal situation. You may be stuck with either software or an entire protocol that just doesn't have the idea of relatively arbitrary back and forth challenges in the middle of authentication. If it sends plain text passwords, you can probably make it work if you try hard enough.

(In retrospect this seems obvious, but I guess I wasn't thinking perversely enough before I started looking into MFA for OpenVPN.)


Comments on this page:

There are some details of the traditional UNIX architecture that are largely "unexplored", for example having multiple password lines for the same identity ("user name") or account ("user id"), and requiring one or N or all of them to be given. Just as there is the possiblity to have multiple identities for the same account, or multiple accounts for the same user name.

http://www.sabi.co.uk/blog/20-two.html?201108#201108

Written on 31 March 2023.
« Giving Gnome-Terminal some margins makes me happier with it
Avoiding HTTP/3 (for a while) as a pragmatic default »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri Mar 31 22:10:48 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.