GNOME Bugzilla – Bug 782480
networkmanager-openconnect automatic form submission gets me locked out of my VPN account because of too many login attempts with an incorrect password
Last modified: 2020-11-12 14:25:24 UTC
Created attachment 351578 [details] [review] [PATCH] Try only once to log in automatically I have to switch between two VPNs at my work, both of which use the same credentials with Duo two-factor authentication. The networkmanager-openconnect applet prompts me for two passwords. The first is my regular password, and the second is a password that I get from the Duo phone app that changes every minute or so. I want to save my regular password in NetworkManager, but then NetworkManager saves the temporary password too, and it becomes very easy for me to get locked out of my account. Here's what happens: 1. I accidentally click the menu item to connect to the wrong VPN. NetworkManager makes 5 connection attempts with the last temporary password, all of which fail. 2. I realize that I clicked the wrong VPN, close the dialog, and click the menu item for the right VPN. NetworkManager makes 5 more connection attempts that fail. 3. Now that I have had 10 failed login attempts in a short period of time, my organization locks me out of my VPN account and I have to call IT support to get back in. It doesn't make sense for networkmanager-openconnect to try to connect 5 times before telling me that the password is wrong. If the connection fails on the first attempt, why would it succeed on the second, third, fourth, or fifth attempt? I am attaching a patch that restricts networkmanager-openconnect to 1 automatic login attempt. This should make it much more difficult for users to be accidentally locked out of their accounts.
Strongly related to https://git.gnome.org/browse/network-manager-openconnect/commit/?h=2a71b3a6bb5091e8b91a26616c41a5a64a7e495d . Lubomir, why did you choose 5 there?
Please note that is a limit on form submission and it sometimes takes more then a single form submission to obtain the login cookie (e.g. ocserv with PAM uses a separate form to request the user name and then a separate one for a password and maybe even an OTP token). Thus the patch is generally incorrect for such cases. I would also tend to think that this is an configuration error on the server side -- if the lockout doesn't expire then your organization already has a rather easy DoS problem. I am not sure what the other options are. What comes to my mind is: * Don't proceed on error responses (4xx and 5xx class). Does your server set these correctly? * Detect loops. If we're submitting the same form twice then we're probably resubmitting after a login failure -- we could just stop at that point.
The server sends 200 OK on failure and there's nothing I can do about it. Aside from detecting loops, there are a few other options: * Let the user pick which passwords to remember, instead of all or none. * Let the user turn off automatic form submission. * Reduce the number of automatic form submissions to 2 or 3. * Check if the first line of the response is "Login failed." Which solution do you like best? Personally, I'm a fan of turning automatic form submission off by default, because currently there's no way in the GUI to edit the username or passwords for a connection unless there is a connection failure.
I'd definitely want to turn off automatic submission. Some users have a setup where the form "password" field consists of a static password followed by digits from an OTP token. They can let the static password be remembered but they still have to add the digits each time. And yes, we should have loop detection too. Each form has a unique form ID and we should never submit the same form twice. No need for looking for 4xx responses or 'Login failed'.
* "Want to BE ABLE TO turn off automatic submission"
I found a workaround: My organization uses Duo for two-factor authentication, and Duo accepts the magic word "push" as a passcode. The OpenConnect applet then pauses at "Contacting host, please wait..." until I approve the login on my phone. This is easier than reading the passcode off my phone and typing it into the computer, and it avoids the problem of multiple failed login attempts in rapid succession.
I believe this is now fixed?
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).