1250004 - Password visible by changing input field from password to text

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[coolcat_the_best2]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

 - I let the Firefox password storage or 3rd parties like LastPass fill in the login form.
 - I open an element inspector (Firefox their own or 3rd party like Firebug)
 - I go to the <input type="password" ... /> element from the login form
 - I edit type="password" to type="text"


Actual results:

I can see the password as clear text and am able to copy it possibly with malicious intentions.


Expected results:

The password field should have been cleared or the contents should be replaced with asterisks. This way there is no way for me to copy the password through unprotected means.

Comment 1

[:Gijs (he/him)]

I believe that other browsers (Blink, at the very least, but I would expect IE/Edge to do the same) behave the same way, that this is correct per spec, and that changing this behaviour would break web pages that allow you to look at your password with some kind of 'view password' toggle.


For the spec, if you go here:
https://html.spec.whatwg.org/multipage/forms.html#signal-a-type-change

and scroll up to the start of the steps, it says:

> When an input element's type attribute changes state, the user agent must run the following steps:
> 
> * If the previous state of the element's type attribute put the value IDL attribute in the value
>   mode, and the element's value is not the empty string, and the new state of the element's type
>   attribute puts the value IDL attribute in either the default mode or the default/on mode, then
>   set the element's value content attribute to the element's value.
> 
> * Otherwise, if the previous state of the element's type attribute put the value IDL attribute
>   in any mode other than the value mode, and the new state of the element's type attribute puts
>   the value IDL attribute in the value mode, then set the value of the element to the value of
>   the value content attribute, if there is one, or the empty string otherwise, and then set the
>   control's dirty value flag to false.
> 
> * Otherwise, if the previous state of the element's type attribute put the value IDL attribute
>   in any mode other than the filename mode, and the new state of the element's type attribute
>   puts the value IDL attribute in the filename mode, then set the value of the element to the
>   empty string.
> 
> * Update the element's rendering and behaviour to the new state's.
>
> * Signal a type change for the element. (The Radio Button state uses this, in particular.)
> 
> * Invoke the value sanitization algorithm, if one is defined for the type attribute's new state.

Both type text and type password use the "value" mode (see second table under https://html.spec.whatwg.org/multipage/forms.html#concept-input-apply ), and so none of the first 3 bullet points apply, so the value is not altered or reset in any way.


Even if this was a spec bug as reported, it wouldn't be a security issue because per spec the current value of the input field is always retrievable by first inspecting the element, and then using:

$0.value

in the console (or doing something similar from JS in the page), and we wouldn't be able to break that without breaking web pages everywhere that use JS-based login forms of one description or another.

While in theory we could make the developer tools behave in some magical way that was different from how web pages see these elements, I don't think that would benefit anyone as you could still obtain the same information using e.g. JS bookmarklets, which are probably easier to maliciously convince people to stick in the location bar than the steps in comment #0.

Taking all that into account -> invalid, and opening this up (not a security issue).

Comment 2

[coolcat_the_best2]

So the only way to make your password storage secure is by needing a password to be able to use stored passwords, not just when wanting to view your password?

Comment 3

[:Gijs (he/him)]

(In reply to coolcat_the_best2 from comment #2)
> So the only way to make your password storage secure is by needing a
> password to be able to use stored passwords, not just when wanting to view
> your password?

That depends what you're trying to defend yourself from, but essentially, yes. Even if we did something against reading the passwords from the page, you could use the network monitor (or wireshark, or a similar tool) to see what the contents of the login request are.

I would assume that lastpass already requires your password in some way, but perhaps only once, when you log onto the machine or into the OS or something like this.