Closed Bug 443345 Opened 16 years ago Closed 1 year ago

Protect password fields with a "Password Booth"

Categories

(Toolkit :: Password Manager, enhancement)

1.9.0 Branch
enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: Joi_28, Unassigned)

References

()

Details

(Keywords: sec-want, Whiteboard: [security:passwords] [sg:want] morphed, start at comment 2)

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.
Severity: normal → trivial
Version: unspecified → 3.0 Branch
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.
Blocks: xss
Severity: trivial → enhancement
Status: RESOLVED → UNCONFIRMED
Component: Security → Password Manager
Resolution: DUPLICATE → ---
Summary: Ajax and password input field → Protect password fields with a "Password Booth"
Whiteboard: [sg:want] morphed, start at comment 2
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
QA Contact: firefox → password.manager
Product: Firefox → Toolkit
perhaps superseded by/subsumed into some of the Mozilla Labs Identity work
See Also: → 653132
Blocks: 1118400
Blocks: 1118540
No longer blocks: 1118400
Priority: -- → P3
Whiteboard: [sg:want] morphed, start at comment 2 → [security:passwords] [sg:want] morphed, start at comment 2
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.

Linking to https://mikewest.github.io/writeonly/ so I can find it later.

Preventing JavaScript from accessing password value on it's own page will be a problem for a few reasons.

  1. We will break a lot of web

  2. Scripts can be used to process password as part of SRP protocols

  3. Nothing really stops bad actor from displaying something similar to what browser does and fooling user to type into custom password field (not to mention that there are custom implementations of password inputs).

Severity: normal → --
Priority: P3 → --

We have discussed this issue and it's a WONTFIX because we can not prevent sites from doing requests or reacting to changes in their inputs.

Status: NEW → RESOLVED
Closed: 16 years ago1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.