AS 2.5.2 User Permissions page deletes passwords on any Save

[gwideman]

When I hit the Save Settings button, to save any settings for either of the two current users, the password of the one non-admin user gets deleted (apparently), preventing that user from logging in to the client web admin.
Repro example:
A freshly installed OpenVPN AS server. Selected "Use local authentication via internal DB". I confirmed that Authentication > General > Local is ON
I added one user 'user2' (in addition to the openvpn admin user.)
I set password on 'user2'. Save, restart. Now user2 can log in to client web UI (using a different web browser).
I then use User Permissions page to edit anything else (say the 'Allow Auto-login' for the openvpn user -- ie: nothing related to user2)... save, etc, and now user2 cannot log in to client web UI.
In the admin UI I then re-enter the password for user2 (save, etc). Now user2 can log in.
I edit something else in the admin UI User Permissions page, again unrelated to user2 (save etc)... and again user2 can't log in to web ui. I can repeat this indefinitely.
Conjecture: On the User Permissions page, the Save Settings button sends all the fields of all the listed users to the server, which is saving all of them into the database. But the form's password field hasn't been set, so it knocks out the existing legit password in the database.
Obviously this behavior is a bit of a train wreck.

[gwideman]

Forgot to mention prominently: This is for Access Server 2.5.2. There is no such version in the bug tracker Version drop-down-list.

[novaflash]

Since this is not a problem observed here on our Access Server 2.5.2 I am pretty damn sure this is caused by a browser plugin doing form filling.

[gwideman]

Hmmm, interesting theory. I have no browser add-ons installed, but it is true that unadorned firefox has a username-password filling feature. I would be surprised that's it, because I saw the password getting lost by just changing one of the checkboxes that enables Autologin, without even opening the user edit panel. However, I will probe further into this possibility, for example explicitly disabling that browser feature.

[gwideman]

Progress:

This is indeed as novaflash suggested: On User Permissions > some user settings panel, Firefox (63.0, Win7-64) over-eagerly fills in the password field. More details further below. But first, OpenVPN-AS is not blameless here.

1. A significant contributing factor is that the Local Password field consists of just a single input field (type="password", ie: hidden characters), instead of the usual two fields which allow verifying that you typed in the new password correctly. that is already a shortcoming by itself. But for the case at hand, if there were two fields, then almost certainly autofill would not operate on the second one, and a bad password update would be detected by form verification code.

2. The second contributing factor is that upon loading the User Permissions page, there is already present in the DOM a div containing the edit form for every user. Even though these are hidden, the fields are present, and apparently subject to FF's autofill function. Hence the disrupted password situation happens even when none of the edit panels were actually opened. This is monumentally misleading, obviously.

3. Why is FF even prompted to autofill this field in the first place? I know little of how FF's autofill function makes such decisions, but it's not obvious why this field draws autofill attention, not being near any field that accepts a username. Maybe the User Permissions page has some inadvertent landmark that gets FF Autofill excited.

Bottom line -- this is not a corner case due to some rogue add-on, it's mainstream behavior of Firefox. It's also pretty obtuse (accept autofill in one context, get it unexpectedly in a different context -- hard for end-users to notice, let alone troubleshoot.) And although dumb on Firefox's part, I think OpenVPN-AS's single-field password changer, always present in the DOM, exposes the user data to disruption in decidedly unrobust fashion.

Now, conditions leading to the reported autofill.

As noted, the proximal cause of the behavior I reported is Firefox autofilling a password field on the User Permissions page. This must be preceded by some previous login to the admin site, where the user accepts Firefox's suggestion to save the username/password used for login. Ie: seemingly nothing to do with the field that's getting unwantedly autofilled.

The problem can be prevented by not allowing Firefox to save username/password for OpenVPN-AS, and if already saved, then deleting it from Firefox's list of "Saved logins" (and possibly putting the OpenVPN-AS site on the Exception list to not suggest saving credentials).

It may well be that Firefox autofills only the first password field that it sees on the User Permissions page. I can't test this well, as I think I'm currently limited to two users, the initial one ('openvpn'), and myself, 'grahamvpn', which appears first in the list of users, (possibly due to alpha sort?)... concordant with the idea that "first password field gets autofilled".

(Hmmm, now I think about it, I initially understood the trial license to include any number of users, but only two could log in simultaneously. But in much earlier testing, when I added a third user, one of the previous ones stopped working, making me thing "oh, I guess I can only create two users". I'm now thinking that was actually due to this password-overwrite issue! So that's an actual case-in-point where this behavior was led to a considerable misdirection and wasted hours of time.)

OK, I think that's all I know about the problem. I am unstuck, so thanks for the suggestion on that. But I do think this bears fixing.

[novaflash]

Unfortunately, if this is indeed now the default behavior of Firefox, then we will have to create some sort of fix for this.

Regarding amount of users able to log in when you run access server without a license, we allow an unlimited amount of users, but only 2 VPN tunnels can be active at any time.

[gwideman]

I appreciate your sensitivity to this, it's definitely a trap. And the current resolution, disabling autofill for the actual login to OpenVPN-AS admin UI, of course increases friction while using the product, especially during the learning phase.

If going to the effort of addressing this issue, I hope you all will consider a second password slot for confirming password changes, as that would also be a plus, I believe. Of course, much better if you can also prevent Firefox's autofill on those fields.

Also, I have not tried this scenario in Chrome or IE to see what they do. They may or may not be affected. Anyhow, thanks for your attention to this issue.

[novaflash]

seems like this is a browser side issue, can't reproduce anymore.