Closed
Bug 1118540
Opened 8 years ago
Closed 7 years ago
Secure Filling - don't give javascript access to password fields
Categories
(Toolkit :: Password Manager, defect)
Toolkit
Password Manager
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: tanvi, Unassigned)
References
(Blocks 1 open bug)
Details
Javascript on a login page can scrape the contents of the password field (either when it is being typed in by users or when the password manager fills it in). For a majority of pages, there is no need for javascript to have access to this data. It would be great if the actual password was not accessible via javascript. We could instead use a dummy value or a token and then retrieve the actual value on form submit, never giving the DOM access to it. We could do this in a two step process: 1) For passwords that the Password Manager fills in, use a token isntead of the actual password. Have the Password Manager replace the otken with the actual password on submit - https://bugzilla.mozilla.org/show_bug.cgi?id=653132 2) Extend this to all password fields. (Except registration pages that may be testing password strength; note that this means we'd need to be able to differentiate a login page from a registration page.) - https://bugzilla.mozilla.org/show_bug.cgi?id=443345 The problem with this is that some websites do need/want access to the password field (ex: pages that use ajax to login). We can't do this without breaking some percentage of the web (I have no data on how small or big this percentage is). One option is to allow sites to opt-in to this protection via the Credential Management API[1]. [1] https://mikewest.github.io/credentialmanagement/spec/
Comment 1•8 years ago
|
||
We should propose a spec update instead of violating the spec in silence.
Comment 2•8 years ago
|
||
Note that when someone is not logged in to a particular site (on which they do have an account), revealing their *user name* to the site is already a privacy violation. See for instance http://www.pamgriffith.net/blog/privacy-and-autocompleted-usernames
Comment 3•8 years ago
|
||
I'm pretty sure this is a dupe of some existing bug... I don't think we should do this. It's likely to cause problems with sites that need to look at the password field for legitimate reasons, and if a site has been exploited you'd still need to guard against things like keypress listeners.
Comment 4•8 years ago
|
||
I agree, :dolske.
Reporter | ||
Comment 5•8 years ago
|
||
I've marked the two bugs that discuss this as dependents on this one. Wanted to create this one to talk about the problem in general and what solutions are possible without breaking the web. Perhaps this should be a "breakdown" bug. Going back to comment 0, is #1 would be a good way of dealing with this if it is feasible to implement (and it's also being discussed here - https://bugzilla.mozilla.org/show_bug.cgi?id=1118511#c11). #2 isn't possible in the web we live in today. Maybe it will be one day. In the meantime, we could implement #2 for websites that opt into this type of protection via the Credential Management API.
Comment 6•7 years ago
|
||
This bug as summarized has to be WONTFIX--there are many login pages that depend on the current behavior. Something like bug 653132 might work but we already have that bug and can discuss it there. Not autofilling passwords willy-nilly would also help, but afaik we've wontfixed those bugs (or relegated them to a buried about:config pref, e.g. bug 359675)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•