You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ensure that the vault contains a matching login item (with username and password defined).
Ensure that the browser extension has the "Auto-fill on page load" disabled.
Press Ctrl+Shift+L to auto-fill the username.
PressEnter to submit the username and continue to the next screen for password entry.
Expected Result
Although this aspect is not the focus of the bug report, the user should ideally* have to enter their password in the password field, or auto-fill it by again pressing Ctrl+Shift+L.
Regardless of whether the password field is already populated or not when the user reaches the password screen, the main expectation that is violated by the new behavior is that the user should be required to press the Enter key, or to click the Login with master password button to proceed with authentication.
Actual Result
The user is briefly presented with the password entry form, in which the password value has already been auto-filled.
The major issue is that with no user interaction, the password entry form is automatically submitted after about a second or a fraction of a second. If there is no two-step login requirement for the account, then the authentication is complete and the account opened.
Screenshots or Videos
No response
Additional Context
Although automatic submission of login forms is a popular feature request, until now, Bitwarden's position has been (IMO rightly) that auto-submission would create security risks. Be that as it may, a user who has disabled "auto-fill on page load" should never experience automatic submission of login forms.
In addition to creating a security risk, auto-submitting the login form deprives the user of the ability to augment their password with a manually typed password "pepper" before submitting the login form.
*Ideally, auto-fill should prevent filling of form fields that are not visible (to prevent credentials theft by hidden forms injected by third-party scripts). Thus, in the ideal scenario, the user should have to press Ctrl+Shift+L, then Enter to submit the username, followed by Ctrl+Shift+L and Enter to submit the password.
Operating System
Windows
Operating System Version
Windows 11 version 23H2 (Build 22631.3007)
Web Browser
Chrome
Browser Version
No response
Build Version
24.1.1
Issue Tracking Info
I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.
The text was updated successfully, but these errors were encountered:
I am unable to reproduce this issue, it has been escalated for further investigation. I observe the password field being auto-filled across both the username and password screens from using the keyboard shortcut once, but the password screen does not auto-submit for me.
If you have more information that can help us (such as a video of this behavior), please add it below.
@sammbw Thank you for attempting to reproduce the issue.
I will try to produce a video. In the meantime, I should add that this behavior was observed when logging in to a Web Vault for an account that does not have 2FA enabled. Not sure if that detail may make a difference.
@bwbug not a problem, and no need to provide the video - the two-step login condition was a factor, and I've managed to reproduce this in Chrome today. Many thanks for the additional information, I've passed this along for investigation.
Thanks for the update. There's a subtle issue here, since a Bitwarden Web Vault login is being used to test the behavior of the Bitwarden browser extension auto-fill — the specific example I provided could probably be fixed by preventing the Web Vault login form from proceeding to authentication prematurely. However, I hope that the focus of the bug fix will be to prevent the browser extension from sending whatever signal is causing the login form to be submitted. Otherwise, there may be other login forms on the web that will get automatically submitted on auto-fill.
Steps To Reproduce
Expected Result
Although this aspect is not the focus of the bug report, the user should ideally* have to enter their password in the password field, or auto-fill it by again pressing Ctrl+Shift+L.
Regardless of whether the password field is already populated or not when the user reaches the password screen, the main expectation that is violated by the new behavior is that the user should be required to press the Enter key, or to click the Login with master password button to proceed with authentication.
Actual Result
The user is briefly presented with the password entry form, in which the password value has already been auto-filled.
The major issue is that with no user interaction, the password entry form is automatically submitted after about a second or a fraction of a second. If there is no two-step login requirement for the account, then the authentication is complete and the account opened.
Screenshots or Videos
No response
Additional Context
Although automatic submission of login forms is a popular feature request, until now, Bitwarden's position has been (IMO rightly) that auto-submission would create security risks. Be that as it may, a user who has disabled "auto-fill on page load" should never experience automatic submission of login forms.
In addition to creating a security risk, auto-submitting the login form deprives the user of the ability to augment their password with a manually typed password "pepper" before submitting the login form.
*Ideally, auto-fill should prevent filling of form fields that are not visible (to prevent credentials theft by hidden forms injected by third-party scripts). Thus, in the ideal scenario, the user should have to press Ctrl+Shift+L, then Enter to submit the username, followed by Ctrl+Shift+L and Enter to submit the password.
Operating System
Windows
Operating System Version
Windows 11 version 23H2 (Build 22631.3007)
Web Browser
Chrome
Browser Version
No response
Build Version
24.1.1
Issue Tracking Info
The text was updated successfully, but these errors were encountered: