Bug #8122
open
openvpn client is unable to use OTP (temporary) passwords
0%
Description
While the upstream OpenVPN client is able to load one-time passwords from the file mentioned by the auth-user-pass parameter, it seems the pfsense prevents users from using it.
a) if user does not specify user/password the UI is forcing them to pick certificate authentication method which would break login
b) if user is specifying user/pass, pfsense will save them inside a file like /var/etc/openvpn/client1.up and add the "auth-user-pass /var/etc/openvpn/client1.up" to the config.
This means that even if a power-user managed to create this file with the temporary credentials, these will be overriden and the login process would fail.
If the user is trying to manually specialy the auth-user-pass param as advanced config options, the final openvpn config file will contain that option twice, and the openvpn client will just load the first one, which happens to always be the one invariable user/password combination specified int the UI.
Due to the combination of a) and b) the user is totally unable to configure OTP logins.
There may be multiple ways to address this issue but one option that could be very friendly would be to allow to specify command that generates the password (stdout = password).
One real use case is that user would put there something like: echo -e "fixedpart$(/usr/local/bin/oathtool --totp -b AABBCC...)"
By allowing an arbitrary command to be run, you would give users flexibility to gather their temporary password from various sources like cli tools or even from the web by using curl.
Another option that could work it would be to make the "Custom options" override system options, so if someone defines a line starting with auth-user-pass on custom options, this would override the openvpn line instead of just being appended to the file.
This 2nd approach would fully work if pfsense network up is also able to execute a "pre-up" shell command before trying to establish a connection. I observed as being possible to do this with Viscosity OpenVPN client and also with the Linux OpenVPN client but not with pfsense. If this is possible, is clearly not documented. Being able to run a pre-up command is essential in order to be able to write temporary/OTP credentials into the auth-user-pass file.
Files
Updated by Sorin Sbarnea over 6 years ago
PR implementing this feature https://github.com/pfsense/pfsense/pull/3877
Updated by Sorin Sbarnea about 6 years ago
I attached a screenshot of the initial implementation as it would make easier to review it.
I know that there are security concerns regarding what the user may write into this shell script, so we need to evaluate several aspects.- hardcoding a specific OTP tool would limit use, preventing people from using other ways. For example some users may want to obtain the token using a curl http request.
- oathtool is not included with pfsense distribution, so user would have to install it
- configuration export/restore : as seen this adds a new field containing the script. obviously that if the executed command is not present on the new device the command would fail to run, but the same is valid even of other GUI configurable options like the cron entries. What is important to check for is that restoring the config on another device (maybe even older) should not break it. I think that presence of a new config field would be harmless.
This is also linked to https://community.openvpn.net/openvpn/ticket/960 which asks for direct support in OpenVPN itself, but so far there was no feedback from the core team on it.
Updated by Jim Pingle about 6 years ago
As implemented, this script would only be run when the OpenVPN client configuration is re-written, which happens when the client is saved or resynchronized (e.g. boot time, WAN event, etc). It does not get re-run when the client is disconnected and must reconnect, so it would fail at that time since the OTP token would no longer be valid.
Thus, I don't think the PR method is viable, and that's not even getting back into the serious security and logistical concerns.
This really must be implemented directly in OpenVPN so it can call the script whenever an authentication event happens.