Unexpected/incoherent behaviour in the saved passwords management
Reported by
mauro.sp...@gmail.com,
Feb 26 2018
|
||
Issue description
Chrome Version : 66.0.3355.0
OS Version: 10.0
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari:
Firefox:
IE/Edge:
What steps will reproduce the problem?
1.Save the username and password in a login form
A.CORRECT PATH
2A.Access the chrome://settings/passwords
3A.Click on "Show password"
4A.The "Windows security" window is shown asking for the current Windows account password as a further step to see the passwords
B.UNEXPECTED/CONTRADICTORY BEHAVIOUR (given path A)
2B.Access the login page again
3B.Select the desired login username
4B.The password field will contain the password hidden (*******)
5B.Right click on the password field and inspect the element
6B.Remove the attribute type="password" from the field
7B.The password is now visible in clear
What is the expected result?
The two paths should be coherent showing the passwords straight away always or never.
What happens instead of that?
In the first path (A) the password access is restricted but within the second path (B) it is easily accessible.
Please provide any additional information below. Attach a screenshot if
possible.
The "Windows security" feature in the chrome://settings/passwords page gives a false sense of further security to the user that can, in reality, be easily bypassed.
Other browsers, like Firefox, don't even try to secure the passwords in the password manager but the behaviour is coherent throughout the application.
FURTHER NOTICE: when asking the user if she/he desire to save the password, a warning about having the password store in clear should be shown. True is that someone can access the page anyway when the user saved the login, but given the bad habit of many users of using a single password for many services in this way is easy, discovered the password in one login page, to access all the other services. At least warn the user about the danger.
UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3355.0 Safari/537.36
,
Feb 27 2018
In general we don't protect passwords from a local attacker. Reauth is a feature we implemented after a lot of bad PR. It was too trivial to look up any password. Now it's not and in some common cases it's sufficient (e.g. a curious brother). We definitely are not going to revert the reauth. We are considering strengthening protection for some of the users by master password. Re: warning. We don't want to send contradicting messages. We believe that using the password manager is better for security than memorizing the passwords. Therefore, we don't want to scary people away. Given that the passwords are autofilled later I think it's pretty clear that an access to the computer means an access to their stored account. |
||
►
Sign in to add a comment |
||
Comment 1 by susan.boorgula@chromium.org
, Feb 26 2018Labels: Needs-Triage-M66