User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008062122 Minefield/3.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008062122 Minefield/3.0 If you use a Ajax-Send-Request in combination with a passwordfield and the onChange()-Event every password I type is submitted to the server; even if I do not submit the whole form. It's a potential security risk in my eyes; For standard input it may be a good idea to use Ajax in this way; for password fields I strongly recommend a different policy. May even be used for some XSS attacks, but I did not verify my assumption here. Reproducible: Always Steps to Reproduce: 1. Set up a page like http://www.xul.fr/ajax-post-text.html with passwordfields 2. Add a onChange()-Event in the password-input-field. 3. In the event handler write the passwort to a PHP script; e.g.: xhr.open("POST", "write.php", true); xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); xhr.send(content); Actual Results: More passwords from the user, even if the user did not submit it. May be used for XSS, too. Expected Results: Passwords should just be send if and only if I hit "submit" or similar buttons.

Since a duplicate doesn't add value, especially to a bug buried as INVALID, I hope Kai/Joi doesn't mind if I morph this bug into an enhancement request that would be one way to resolve the issue described in comment 0. The original complaint is that the HTML <input type="password"> element is behaving as specified, and as such is pretty much INVALID unless we can get the spec changed. We may, however, be able to do handle passwords outside the page context and make the entire process safer for users. One such proposal is the "Password Booth" described by Daniel R. Sandler and Dan S. Wallach in their recent paper "<input type="password"> must die!" paper: http://seclab.cs.rice.edu/w2sp/2008/papers/s1p2.pdf slides: http://seclab.cs.rice.edu/w2sp/2008/presentations/w2sp08-dsandler-password-must-die.pdf The idea is to move the password interaction entirely out of the page into a chrome element, that when done would directly submit the information to the form target without putting it back into the page. This might break some pages that rely on being able to grab the password value to do some preliminary processing but would make the vast majority of pages safer. For pages that don't work perhaps we'd have a checkbox on the Booth that said "never use for this site" The password manager could be made to work with the Booth, prefilling when values are known. This would effectively fix my complaints about the increased XSS danger from the current auto-filling password manager and would be somewhat safer than my "click to fill-and-submit" infobar suggestion since it would be form-specific.

How would users know when to check the "Don't use Booth for this site" box? When they see the site break?

Hi all, or just add a security warning if a JS-script tries to access a password field.

perhaps superseded by/subsumed into some of the Mozilla Labs Identity work

Theres also the issue of once a user enters a the master password, then a script can modify then input type='password' to type='text' and then grab the text value and ship it off to some url via document.write... all they have to do is have their server setup as a reverse proxy to say.... google.com, then grab the page server side, render it in a response to the client, then use history.push() or create a window with no url bar that renders a fake url bar at the top and boom. Session hijacked. Cant we move away from passwords and only support two-form authentication? Or create some kind of native identification system that uses your fingerprints/face and email/text to identify a machine once and allow that machine to log on to all sites that it has access to? The machines could use public keys to read data and private keys to write it allowing all data to be encrypted... heck ... even the filesystem could save files in that same cipher Then have a nice publicly accessable list of public keys thus ensuring the validity of all communication... Wheres the innovative ideas people??

(In reply to mike from comment #7) > Cant we move away from passwords and only support two-form authentication? Or x.509 certificates.