disallow empty passwords ? #417
Comments
|
I cannot upload screenshot. Something changed in github upload :( |
|
In OpenVPN core, empty username is not allowed, but empty password is not an error. I guess passing only username has its use cases like SSO where the auth process is federated out, or done out of band by other means. In such cases one may not want to send the password to the server. Ideally, we should have a way of indicating in the prompt process what inputs are required so that the rest can be greyed out in the dialog. Then it would be appropriate to demand a non-empty entries for all enabled inputs including password. In v2.6, we have some newer methods to support out of band authentication, but I don't think the initial username/password prompting has been improved. We could stop making OK the default button as soon the username is filled-in so that hitting return would not submit the dialog if password is empty. Do this without disabling OK so that it could still be clicked with empty password. |
|
may I suggest the following approach ?
or .... we can keep current default behaviour, but introduce additional flag in config, if it is set, empty passwords become disallowed |
|
Could the GUI present a user dialogue window asking for empty password confirmation ? |
|
Let's not make it more user-unfriendly. Those who mistakenly submit empty passwords is no different from those who mistype passwords. At best, we can make none of the buttons as default until all fields are filled in. That should take care of those who hit enter without filling in the password. At the same time allowing the user to press the OK button with empty password. Its either that or leave everything as is. |
|
Make the user select a button and not have |
|
disabling buttons and outlining mandatory fields as red would be nice |
|
Hi,
On Wed, Apr 21, 2021 at 10:11:23PM -0700, Ilya Shipitsin wrote:
disabling buttons and outlining mandatory fields as red would be nice
I think pressing enter *in the password field* should still serve as
"OK!". Otherwise it would annoy me (have to move my hands an extra
time to the mouse).
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
|
|
Maybe Enter should change focus to password field if password is empty and OK otherwise? |
|
just to mention, this is actually pretty rare situation. only when moving to new PC, user fills empty fields for the first time. and sometimes he did not press Tab button to switch fields |
|
hi,
On Wed, Apr 21, 2021 at 11:43:51PM -0700, Ilya Shipitsin wrote:
just to mention, this is actually pretty rare situation.
usually, both fields are filled, password is saved and login happens automatically (without even pressing Enter)
only when moving to new PC, user fills empty fields for the first time. and sometimes he did not press Tab button to switch fields
We always have to fill password field, because it's used for 2FA challenge.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
|
|
I wonder whether "empty" password happens in case of 2FA. From my observation it should happen more often than I see for static passwords |
|
Hi,
On Thu, Apr 22, 2021 at 02:57:31AM -0700, Ilya Shipitsin wrote:
I wonder whether "empty" password happens in case of 2FA. From my observation it should happen more often than I see for static passwords
Never seen that. But as long as I can press <return> in the password
field (after having entered something) I'm fine with the suggested change.
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
|
|
Turns out that there is no good way to do this while still allowing empty passwords. Having no default button doesn't seem to play very well in Windows dialogs. I would have liked to keep allowing empty passwords -- it has its use cases and is supported by the core -- but may be the right way to do that would be have an explicit way for prompting only username. So our options are (i) enable the OK button only if password is non-empty or (ii) leave this as is. (i) would be a regression but probably no one cares. In all cases, enter will submit once the OK button is enabled as it's the default button. |
|
Is empty password a common case? We may introduce some setting for that |
|
Just a punt for an option, how about an empty checkbox: If the password and checkbox are both empty then throw an error. And I guess the checkbox state would also be saved and reset only by user or re-install. |
|
yeah, either checkbox or config setting (so, config would be delivered right with empty passwords) |
|
I decided to go with @chipitsine 's original suggestion -- i.e., require non-empty password (PR #419). If the administrator doesn't want the user to submit a password, one should not prompt for it. So instead of making it even more difficult for the user having to ignore an input and also click additional check boxes, let's just say password input is required if prompted for. The "submit only username" can be handled when OpenVPN grows proper support for indicating it. |
|
You've just made it absolutely impossible to connect using perfectly valid config (with empty password), because some people forget to press TAB. Did I get it right? |
|
Why is your config asking for a password if "empty" is a valid answer? Just leave auth {{{--auth-user-pass}}} from the config and be happy everafter. |
|
I think it is still asking for username as far as I understand. |
|
I was reluctant to not allow empty password, and was a compromise. Given that openvpn.exe expects a non-empty username, but accepts empty password, this was not a smart change. |
|
If a configuration requires an empty password you should not use |
|
Empty password currently serves as a way of providing a username even when password is not in use or when password has to be submitted by other means. Eg., when the actual authentication is federated out, submitting just the username is a useful feature. In such case one doesn't want to expose the password to the server. There could be other uses of username-only. So, unless we add a new option like auth-username, supporting empty password is a useful thing. Not saying that showing a dialog with two fields when only one is required is good UX. |
|
A security researcher friend of mine asked me how this issue is supposed to be linked to my CVE so I would like to point out to anybody else who stumbles upon this that they linked the wrong issues in the v2.6.7 release notes. The correct links were supposed to be the following (same numbers but different repository/type): |
we observe the following pattern in user behaviour: when they setup new PC, sometimes they forgot to press TAB to switch to "password" prompt and type password right after the login, i.e. userpassword.
thus, password itself is empty, and sent as empty.
I'm not sure whether empty password is legitimate, maybe we should change OpenVPN-GUI behaviour to disallow empty passwords ?
I'd suggest to make "password" field red if OK is pressed on empty password. Thus we even do not have to translate it.
@selvanair , what do you think ?
The text was updated successfully, but these errors were encountered: