See the second paragraph of https://www.chromium.org/Home/chromium-security/security-faq#TOC-What-about-unmasking-of-passwords-with-the-developer-tools- .  Although this is a slightly different situation, this applies here as well.

After all, chrome just showed you the password when it generated it, and it is trivial to generate another one before submitting it.

This isn't a security issue for the reasons described in Comment #1.

Unmasking the autogenerated password is intentional. The use case is that if the auto-generated password didn't meet the site's complexity requirements, the user should be able to recover by fixing it. For instance, on that test site, they require a particular length and character set and if the autogenerated password doesn't meet it (by default, it's too long), allowing the user to fix the value manually is a desirable feature.

If you completely delete the generated password (using the delete key) we "reset" back to the initial state, where the text is obscured and the offer to generate a password reappears. This is good.

An unhandled corner-case exists when the user hits CTRL+A to select the entire generated password and, instead of hitting DELETE, types a fully new password. This complete replacement of the password text isn't treated as a "reset" and we act as if the user is simply updating Chrome's generated password. In particular, we keep the text unobscured AND we auto-save the password without asking the user. That feels slightly wrong.

Password Manager folks?

Thanks for the report (and for the clarification in #2)!
Adding the people directly working on generation, because the CTRL+A behaviour sounds like something we should fix before launch.

Adding Blink Editing folks for help.

Context: Once a user accepts a generated password, Chrome reveals the value of field on focusing. A user should clear the field (i.e. make the value empty) to turn off revealing. It means the field doesn't contain a password generated by Chrome anymore, so the field should behave like regular password field, i.e. do mask passwords. 

Problem: A user can generate password, selects the entire value of the field and starts typing. The generated password is gone, but our code cannot detect that because the field wasn't empty. The field's value was switched from the generated value to some user value.

Question: can we distinguish editing the value and replacing entire value of a field?


We face similar problem in  Issue 782164  where password manager overrides the generated value. So, the value shouldn't be treated as generated password anymore. 

Thanks.

tkent@chromium.org yosin@chromium.org kochi@chromium.org: friendly ping.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I retested on Chrome version 70.0.3538.102 (Linux), and the issue looks fixed.

Hitting Ctrl+A and typing any character replaces the visible text of generated password with a masking dot indicating one (hidden) character.

(The fact that after generating a password it gets displayed on focus is by design.)

this is not fixed completely. Typing one character hides the password, but you insert a string of at least 4 characters, the password will be still treated as generated.

 Issue 913651  has been merged into this issue.

Tested 71.0.3578.98 on Linux and OSX and can confirm that this bug has not been resolved.  When I suggest password and then focus into the password field, the password is revealed (expected behavior), but when I CTRL+A and type a single character, it is still visible.  The field only becomes hidden when I focus on another element/window.