373149 - PM Does Not Need To Expose Password Until Transmit Time

Status: RESOLVED WONTFIX

(Toolkit :: Password Manager, enhancement)

Description

[Robert Chapin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

From Bug #360493 came an idea similar to data tainting, except easier.  Instead of handing the real password to the form input, simply force it to display some dots in the field, and then hand off the real password to the transmission routine at the appropriate time.

This is complicated by some cases where scripting of the password value may be desired.

Still, if it were possible for the form to not contain the password value, the surface of attack would be greatly reduced.

Reproducible: Always

Comment 1

[Stuart Morgan]

I'm not clear on what the benefit here is. If an attacker has the ability to use JS then the password can be read with an onsubmit handler (which, as you allude to, some sites do for non-malicious reasons), and if they don't then how would they read the password value before it is submitted?

Comment 2

[Robert Chapin]

Scripting of passwords is the kind of thing I imagine happening inside the IE "Trusted Sites Zone".  Do you have some example sites that I could look at to get a feel for the practical concerns?

Comment 3

[Stuart Morgan]

I can't remember where the example I've seen of this was, but basically the site was doing an onsubmit hash of the user's password, clearing the password field, putting the hash into a hidden field, and submitting the form that way. What possible use they thought this would serve I have no idea, since it adds essentially nothing to security, but there it was.

It seems like this would break exactly the same things as making password fields not readable via JS, cover the same cases, and be harder to implement.

Comment 4

[Robert Chapin]

Well, that hash would hide the plain text, whatever that's worth.  Overall, it sounds like a poor man's SSL to me.  Is that really the only example?

Comment 5

[Stuart Morgan]

(In reply to comment #4)
> Well, that hash would hide the plain text, whatever that's worth.  Overall, it
> sounds like a poor man's SSL to me.

It means that the hashed password is itself the actual password for the site, so the plaintext password no longer matters (except to the extent that people use the same password on other sites). Still, whether it makes sense or not isn't the point.

> Is that really the only example?

I haven't scoured the entire internet and all existing intranets, I'm not in a position to say. IIRC it was some prebuilt bulletin board system, so probably other sites use it.

The points that do matter are:
a) there are legitimate sites that would be broken by this change, and breaking legitimate HTML and JS isn't generally considered a good idea,
b) if a) were fine, then making password fields unreadable by JS seems like a better approach anyway, and
c) you haven't explained what scenario you think changing this behavior would fix (comment 1)

It makes more sense to frame bugs like this in terms of desired behavior and/or the problem you are trying to fix than to frame the problem in terms of one possible way of addressing it.

Comment 6

[Justin Dolske [:Dolske]]

(In reply to comment #3)
> I can't remember where the example I've seen of this was, but basically the
> site was doing an onsubmit hash of the user's password, clearing the password
> field, putting the hash into a hidden field, and submitting the form that way.

You're almost certainly thinking of bug 257781, where pwmgr was made to work with vBulletin logins by processing a submitted form before the content's onsubmit handlers run.

That's an example of a widespread web app which would be broken by changing when pwmgr fills in a password. I'd suspect there are also lots of sites checking |pwfield.value.length|, to ensure you've entered a password before submitting to the server (ie, client-side form pre-validation).

Perhaps there's some heuristic pwmgr could use to determine when it can delay filling a form until after the content's onsubmit executes. (Patches welcome!) However, I suspect that would be fraught with frail logic.

Comment 7

[Stuart Morgan]

(In reply to comment #6)
> You're almost certainly thinking of bug 257781, where pwmgr was made to work
> with vBulletin logins by processing a submitted form before the content's
> onsubmit handlers run.

Actually, I was thinking of what turns out to be the corresponding bug for Camino, which I'd closed as infeasible without knowing that Firefox had already solved that problem. Thanks for the pointer ;)

Comment 8

[Biju]

(not the stored password, but new one)
one example is gmail, it read password field while creating new id to check pwd strength, so do many new sites. 
Also some sites do it to compare pwd and conformation pwd field 
while creating id, changing pwd etc.

(In reply to comment #4)
> whatever that's worth.
> Overall, it sounds like a poor man's SSL to me.
> Is that really the only example?
It is good thing, even the orignal site wont know real pwd.
So even if somebody got read access to pwd table in the websever database.
or on a copy of it, only that site will be compromised.
Account of the same users on another site with same readable pwd will be safe.

Comment 9

[Robert Chapin]

Thanks Biju.  This is why the PM idea is better than turning off JS for password fields.  Almost all of the legitimate needs for scripting password fields are not related to saved passwords.  Registration and password change situations will always need some client-side validation, which is not currently provided by HTML.

Comment 10

[Stuart Morgan]

(In reply to comment #9)
> Almost all of the legitimate needs for scripting password fields are not
> related to saved passwords.

Can you back that up with numbers? I was wrong about (b), but "some sites that need JS access to passwords don't need it for login" and "almost all of the legitimate needs for scripting password fields are not related to saved passwords" are not even remotely equivalent statements. One popular real-world example has already been provided, and you've given no evidence that there aren't plenty of others. (a) isn't something that can be hand-waved away.

And to try one more time: could you please respond to (c)/comment 1, without which discussion of implementation details is pretty much pointless?

Comment 11

[Robert Chapin]

Yeah I wasn't clear on that question.  If you're asking is this particular idea related to XSS protection, then yes that would be one of the practical benefits.

Comment 12

[Mike Connor [:mconnor]]

I've seen enough sites that hash the password onsubmit that this would break a lot of the web (basically all of the sites we fixed password manager for in bug 257781).  So the summary here is bogus, because obviously it does in order to work with the current web.

Robert, other than mitigation of one possible use of a successful XSS attack (it wouldn't protect against XSS itself, it would just make it harder to use that XSS attack in a specific way), are there any other benefits here?

Comment 13

[Justin Dolske [:Dolske]]

Rereading the comments here, I don't see how this could be implemented without breaking the web.