This isn't a security issue; a local attacker can get the password in myriad ways.

For instance, an attacker can simply right-click the password field, choose Inspect Element, and get the raw password.

Please see:
https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#What-about-unmasking-of-passwords-with-the-developer-tools

Yes we can do this using inspect element. But my point is if you keep the system more open (having password at multiple place) then application will be more vulnerable.

Consider a scenario we don't have auto fill password in change password function
--------------------------------------------------------------------------------
The victim is sign-in to the application and went for a coffee keeping the system unlock. In that case if malicious get the system he can't  play around with the inspect element because victim is already sign-in to the application. The only this attacker can do take the session ids, in that case it will only impact that particular session.

Consider a scenario having auto fill password in change password function
-------------------------------------------------------------------------
In this case attacker can use the inspect element as well as change the password to take control of password and complete account. 

This is a security issue and not a functional bug. I checked the same behavior in other browser, IE don't fill the auto fill password in change password functionality and Mozilla ask for master password when you navigate to change password and then auto fill the old password.


Thanks, Sabya 

> In that case if malicious get the system he can't play around with the 
> inspect element because victim is already sign-in to the application.

The obvious attack would be to simply sign out of the application, steal the password, and log back in. The slightly less obvious attack is to use the JavaScript console to create a password form, inject it into the page, and then steal the credentials.

Incidentally, Firefox 55 autofills the user's existing password when visiting either of these pages https://twitter.com/settings/password and https://twitter.com/settings/your_twitter_data. Internet Explorer's behavior isn't a deliberate design decision, it's an artifact of the fact that the password manager is extremely limited: https://blogs.msdn.microsoft.com/ieinternals/2009/09/10/why-wont-ie-remember-my-login-info/

The obvious attack would be to simply sign out of the application, steal the password, and log back in. The slightly less obvious attack is to use the JavaScript console to create a password form, inject it into the page, and then steal the credentials.

Totally agreed with the above statement, can you help me to understand then why we we are protecting saved password with domain password? Is it a false sense of security?

Thanks, Sabya

Totally agreed with your point, going by your word I feel the domain password which the browser ask when user try to see any password from manage password list is a false sense of security. There is no use of that.

In ideal case the domain password prompt should come when use access the manage password to see the stored password list (basically the application name). In that way at least we can make it one level difficult for the attacker and he has to guess the application name, with some limited time frame.

But currently the browser is asking password when user try to see the password in the manage password, which is of no use.

Thanks, Sabya  

Re #5 and #6: You're correct in noting that the prompt for the device credentials to reveal the password is not actually a security boundary. 

A meaningful number of users requested this feature nevertheless, and thus it was implemented on some (but not all) Chrome platforms.

Do you feel, if we authenticate the user (with domain password) before disclosing the complete list of stored application password/website name has some value rather authenticating the user in display password event.

I feel it will be more challenging for the attacker to guess the website name and try the attack. Now it is straight forward as you mention, see the list and browse the application fetch the password from inspect element and close the browser.

Any updates on the last thought?

It would certainly be ever-so-slightly more private to require the user to authenticate before seeing the list of passwords. Of course, most casual attackers are interested in the credentials for a specific site (and thus they'll just try it) and most serious attackers will simply dump the credential list directly from storage instead of bothering with the built-in viewer.