A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Disable “Show password” if autofilled

simevidas
2015-03-05

I think that the “show password” checkbox on login forms is useful (LukeW has recently written about it here) and I’d like to see it on the Web. Luke points out that this feature is a security issue in the presence of the browsers’ autofill mechanism (when the user chooses “remember password” and later has the password field autofilled by the browser).

How can we circumvent this issue?

  • Should browsers just refuse to reveal an autofilled password on the page (even when input type is switched to 'text' via JavaScript)?
  • How can web apps detect autofill (needed for conditionally enabling the “show password” checkbox)?
  • How much of this should be standardized?

Btw, I’ve noticed an IMO ideal implementation of this functionality in ESET’s security software. See a video demo here.

robin
2015-03-06

I understand the threat, but I’m not sure that this should be standardised. If the attacker has access to the user’s browser, even if the browser removes the password when the input is switched to text, the attacker can still get the value by hitting the JS console and looking at the input’s value. And you can’t remove that as it’s needed for logins that work through XHR.

So the attack is really just the case in which there is a Show Password checkbox and the attacker has a split second in which to click it but not the time to open the console. I’m not sure browsers could defend against that without causing issues for legitimate uses. The better solution is to get rid of login dialogs altogether :smile:

I guess that a Web app can detect this by noticing that the password field has been filled out but has never been focused. In that case, it could disable its Show Password checkbox until such a time as the password field has been both focused and cleared. Technically it’s not hard; I’m not sure that there wouldn’t be cases in which it might confuse users though.

simevidas
2015-03-06

Ok, I can make a proof of concept when I find time. I think it makes sense to have the Show Password functionality disabled at first and then enable it on user input (after making sure that the current value consists exclusively of direct user input).

jonathank
2015-03-06

I suspect pages could protect the fields themselves against extensions or malware a little with: http://www.w3.org/TR/UISecurity/


However it would be nice that password itself could be set from the browser side, something similar to this:

<input type="password" prefilled />

Typing in the box would be the equivalent of their being a place holder on the element and removing prefilled.

If the form gets submitted the memory reference is never shown to the user or the JS but could be used to send to a server.

jonathank
2015-08-08

This is somewhat related to: Write-only input fields

I the Credentials Management API will likely help solve this form of issue however it won’t solve it for medical data or card information.

This is however in a way harder to solve than write-only-input-fields as it requires the prevention of third party scripts to not be allowed to inject their own form to inspect the value that gets prefilled.