Passwords can be accessed by Chrome Extensions having access to the JS DOM (any Chrome extension) and also, disregarding any theoretical or very practical malware -

Any co-worker who can access your computer when you're at lunch can read your passwords with one line of simple JS or access to a Mouse with a Right click:

     console.log(document.getElementById("pw").value)

Deleted: Bildschirmfoto 2017-07-27 um 17.27.48.png 229 KB

	Bildschirmfoto 2017-07-27 um 17.27.48.png 229 KB View Download

A browser cannot protect data when it is running on a compromised PC.
A browser cannot protect data in the face of an attacker's unrestricted physical (or logical) access to a PC.

Details:

https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model- 

https://dev.chromium.org/Home/chromium-security/security-faq#TOC-What-about-unmasking-of-passwords-with-the-developer-tools-

https://technet.microsoft.com/en-us/library/hh278941.aspx

Browser extensions can be prevented from reading input[type=password] fields.
The browser can, very well, encrypt the password in memory and only decrypt in while use.

Browser extensions can be prevented from reading input[type=password] fields, explicitly after Autofill - Chrome knowns well Autofilled; Simple Information Flow Tracking task.

> Browser extensions can be prevented from reading 
> input[type=password] fields.

Re #3: Preventing a browser extension from reading INPUT TYPE=PASSWORD fields wouldn't be effective, as a browser extension with the permission to do so would also have the permission necessary to inject JavaScript on the page. JavaScript in the page inherently may exfiltrate data from the DOM, including the value of any input field, via myriad of vectors. When users grant powerful permissions to extensions, those extensions become powerful.

>The browser can, very well, encrypt the password in memory and
>only decrypt in while use.

It's true that the browser could keep an encrypted password in memory, and decrypt it only when added to the DOM, at which point it would be copied to JavaScript, network requests, etc. 

However, unfortunately keeping the password encrypted in memory is not very useful, as the decryption key would itself also be in memory. An attacker with the ability to steal the unencrypted credentials in memory today would also have the ability, were such an encryption scheme introduced, to steal both the encrypted credentials and their decryption key, rendering the protection moot.

 Issue 750192  has been merged into this issue.

>Re #3: Preventing a browser extension from reading INPUT TYPE=PASSWORD fields wouldn't >be effective, as a browser extension with the permission to do so would also have the >permission necessary to inject JavaScript on the page. JavaScript in the page >inherently may exfiltrate data from the DOM, including the value of any input field, >via myriad of vectors. When users grant powerful permissions to extensions, those >extensions become powerful.

There is websites who abuse popups, fullscreen mode, Javasscript and combination of PDF and <object> type internal JS DOMs to explicitly force users to only be able to shut down the computer loosing all of their work, or to klick on Install of the CRX iN Chrome. I am quite sure the most powerful security team on earth, at Google, has already seen such sites. 

> It's true that the browser could keep an encrypted password in memory, and decrypt it > only when added to the DOM, at which point it would be copied to JavaScript, network > requests, etc. 

> However, unfortunately keeping the password encrypted in memory is not very useful, > as the decryption key would itself also be in memory. An attacker with the ability to > >steal the unencrypted credentials in memory today would also have the ability, were > such an encryption scheme introduced, to steal both the encrypted credentials and their > decryption key, rendering the protection moot.

I am very confident that you aware of process protection procedures, such as used in Counter-Forensics or Game Cheating Protection. I am also quite sure you aware of non-full decryption keys in RAM, having to be brute-forced a little bit, as in a few bits of it, which be done in few milliseconds. I agree with you the latter would be pretty stupid, while plugs into the process could be easily detected, and rather than demotivating security researchers you could at least pretend to do something. THANKS.