User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060907 Firefox/1.5.0.5 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060907 Firefox/1.5.0.5 javascript:(function(){var inputs=document.getElementsByTagName('input');var n=inputs.length;for(var i=0;i<n;i++){if(inputs[i].getAttribute('type')=='password')inputs[i].setAttribute('type','text');};})(); Using this favelet on a login page containing tag <input type="password"... reveals the password. Opera catches input field type change and clears password so it is not disabled in plain text. Reproducible: Always Steps to Reproduce: 1.Go to some login page, enter password - only asterisks are visible 2.Paste attached javascript favelet into address bar, press enter 3.Voila - password revealed Actual Results: All passwords on a page are revealed Expected Results: Input field should be emptied when type attribute changed

Update: favelet can also display the password - alert(passwordInputElement.value)

The browser and the page can access your password at any time when you type it in the password field, and you're just discovering ways to access that data.

Of course the page can access the password, but not anybody who sits in front of the computer should. Why then hide passwords with asterisks and disable copy-pasting if anybody can simply view it with a favelet? I really think it should be completely write-only from userspace...

You don't need a bookmarklet - you can simply see them in Options > Privacy > Show Passwords. If more people can use your browser and you don't want them to access your passwords you should set a Master Password.

Yes, but this bug is making the master password useless - if I want to know your password, why would I bother with guessing your master password when I can simply go to the web I am curious about, enter your login and use this bookmarklet? And more - let's say this is fixed so that when input's type attribute changes to from 'password' to 'text' firefox empties the value - if so (like Opera does this), there is still the possibility to alert() the password value, this isn't fixed even in Opera yet. Javascript code not coming directly from the document should not be able to read passwords. The problem will be how to prevent this - because script still can be appended into documents DOM tree... so maybe remember for each script if it was requested by the page(?)

> Yes, but this bug is making the master password useless - if I want to know > your password, why would I bother with guessing your master password when I can > simply go to the web I am curious about, enter your login and use this > bookmarklet? If you use a Master Password, web passwords won't be filled in until you enter your Master Password. If that weren't the case, you'd have more problems than bookmarklets revealing web passwords. > Javascript code not coming directly from the document should not be able to > read passwords. The problem will be how to prevent this - because script still > can be appended into documents DOM tree... so maybe remember for each script if > it was requested by the page(?) Bookmarklets are treated as scripts coming from the page and I don't think this is a good reason to change that.

This functionality is in the HTML spec, and this technique works on IE, Opera, and Safari in addition to Mozilla-based browsers.

Well, on change of input element's type attribute, Opera clears that element's value, too. Weird is, that without changing type attribute, value can be alerted. Argument about how other browsers suffer of this doesn't sound as good enough justification (at least to me)

If we didn't allow scripts to see the values of password fields, we'd break many login forms.

confirming

If this is going to get confirmed let's be clear about the hypothetical attack being proposed here: 1. you supply the master password 2. you leave (without locking your computer) 3. someone with access to your computer comes along 4. they navigate to a site to which you are not yet logged in. 5. they get the password manager to fill in the password (on some browsers they may have to click a toolbar button) 6. they run a javascript: uri to get your password If you don't have a master password they just copy your whole password file and play as long as they want back on their own machine. If people you don't trust have access to your computer you should be locking it. Stealing passwords is the least they could do (see http://www.codinghorror.com/blog/archives/000997.html ). Even without this feature they could install things to steal your passwords. If you are already logged in to the site they want the password for then they can already access the information. On some sites they can see the password or have reminders sent to their address, on others they could lock you out by resetting the password. Even if you weren't logged in and the password field was completely unreadable, because the computer and the master password is unlocked they can go ahead and log in to that site and do what they want/can. Or they could simply type a little bit of javascript to change the form method from POST to GET, submit the form, and read the password right out of the parameters in the address bar. Or submit the form to their own site or a site that echoes back what it got for test purposes. Maybe you're worried that the site you're logging into has an XSS hole and that that will be used to read the field value. Blocking the field value won't stop them, they can always trap keyboard events or redirect the form post to their site (you wouldn't necessarily notice this) and get your password anyway. The spec says "the current value is the text entered by the user, not the text rendered by the user agent" and notes that this is "light security" to protect against "casual observers", that is, shoulder-surfing. http://www.w3.org/TR/html401/interact/forms.html#input-control-types Anyone injecting script (a bookmarklet) into your page is neither "casual" nor an "observer", they are actively hacking you. If you are surrounded by people willing to hack you LOCK YOUR MACHINE.

Another way is to let the browser fill in the password, start DevTools/NetMonitor, submit and read the password in the NetMonitor. Which begs the question, why does revealing or copying the password in Option ask for the master password first?