759860 - Don't auto-populate username/password on http pages - Password Manager

Status: RESOLVED WONTFIX

(Toolkit :: Password Manager, defect)

Description

[Tanvi Vyas[:tanvi]]

To prevent from attacks such as "Lupin"[1], do not auto-populate the username and password on pages that are in cleartext.  Instead, provide the multi-user experience, as seen here:
https://people.mozilla.com/~tvyas/multiuser_experience.jpg

Related feature pages:
https://wiki.mozilla.org/Security/Features/HighlightCleartextPasswords
https://wiki.mozilla.org//Security/Features/PasswordManagerImprovements

[1] Described in upcoming paper "Automated Password Extraction Attack on Modern Password Managers" by Eric Chen, Raul Gonzalez, and Collin Jackson from Carnegie Mellon.

Comment 1

[Johnathan Nightingale [:johnath]]

Adding madhava for UX - I think switching to the prompt should be fine, but it's a change to UX that lots of people (perhaps all people!) will encounter.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I do not think that is a good UX for low-value sites like reddit.com, news.ycombinator.com, and others.

Proposed Alternative:
Show the username in the username field, and show "************" in the password field, but do not actually fill in the fields in a way that the DOM can detect (or in a way that can be submitted) until the user actually clicks the submit button or hits enter to submit the form. We would have to use whatever anti-spoofing mechanism we use to prevent javascript from tricking us with a synthetic click or synthetic keyboard event, but I think that's already a solved problem.

Comment 3

[Tanvi Vyas[:tanvi]]

(In reply to Brian Smith (:bsmith) from comment #2)
> I do not think that is a good UX for low-value sites like reddit.com,
> news.ycombinator.com, and others.
> 
> Proposed Alternative:
> Show the username in the username field, and show "************" in the
> password field, but do not actually fill in the fields in a way that the DOM
> can detect (or in a way that can be submitted) until the user actually
> clicks the submit button or hits enter to submit the form. We would have to
> use whatever anti-spoofing mechanism we use to prevent javascript from
> tricking us with a synthetic click or synthetic keyboard event, but I think
> that's already a solved problem.

That is a good idea.  Thanks bsmith!

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

sec-high because it meets "Obtain confidential data from other sites the user is visiting or the local machine, or inject data or code into those sites, requiring no more than normal browsing actions" and "Failure to use TLS where needed to ensure confidential/security," and because it is definitely worse than the sec-moderate criteria of "Local storage of passwords in unencrypted form."

Comment 5

[[:mmc] Monica Chew (no longer reading bugmail)]

(In reply to Brian Smith (:bsmith) from comment #2)
> I do not think that is a good UX for low-value sites like reddit.com,
> news.ycombinator.com, and others.
> 
> Proposed Alternative:
> Show the username in the username field, and show "************" in the
> password field, but do not actually fill in the fields in a way that the DOM
> can detect (or in a way that can be submitted) until the user actually
> clicks the submit button or hits enter to submit the form. We would have to
> use whatever anti-spoofing mechanism we use to prevent javascript from
> tricking us with a synthetic click or synthetic keyboard event, but I think
> that's already a solved problem.

They're only low value if you don't re-use your reddit password as your banking password (or your email password, which every password-reset scheme escalates to).

However, I'm not sure that this is a good idea. We already know that password manager use is low, and introducing more steps to the UI might make usage drop even more.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Monica Chew [:mmc] (please use ?needinfo) from comment #5)
> (In reply to Brian Smith (:bsmith) from comment #2)
> > I do not think that is a good UX for low-value sites like reddit.com,
> > news.ycombinator.com, and others.
> > 
> > Proposed Alternative:
> > Show the username in the username field, and show "************" in the
> > password field, but do not actually fill in the fields in a way that the DOM
> > can detect (or in a way that can be submitted) until the user actually
> > clicks the submit button or hits enter to submit the form. We would have to
> > use whatever anti-spoofing mechanism we use to prevent javascript from
> > tricking us with a synthetic click or synthetic keyboard event, but I think
> > that's already a solved problem.
> 
> They're only low value if you don't re-use your reddit password as your
> banking password (or your email password, which every password-reset scheme
> escalates to).

OK, but the UX I was objecting to is a bad UX for sites of *all* levels of value.

> However, I'm not sure that this is a good idea. We already know that
> password manager use is low, and introducing more steps to the UI might make
> usage drop even more.

I agree. What I suggest is to keep the UX, as perceived by the user, the same as it is now. No new steps would be added. Only the ability for a network attacker to silently steal passwords would be eliminated.

Comment 7

[Justin Dolske [:Dolske]]

I think the comment 2 proposal is going to be technically complex and probably still be flawed. EG, if a MITM attacker has control over a page, why wouldn't they just fake/force a user logout and then steal the reauthentication? Is the paper in comment 0 published yet? I'm not sure what the threat is we're trying to guard against.

The password manager already stores the protocol (so a password saved from https://site.com will never be filled in on http://site.com), so if we've got a login the user would have already entered it on that page.

Comment 8

[:Gavin Sharp [email: [e-mail]]]

(In reply to Justin Dolske [:Dolske] from comment #7)
> EG, if a MITM attacker has control over a page,
> why wouldn't they just fake/force a user logout and then steal the
> reauthentication?

Because that's typically much harder and is less likely to succeed? :) There can still be value in raising the difficulty-to-exploit bar and/or lowering the probability of attack success, even if there still remain potential attack vectors. "won't solve the problem 100%" is a poor argument when solving the problem 95% has value; "won't solve the problem enough to be worth the downsides" is a more reasonable objection but harder to gauge (need to subjectively evaluate the tradeoff).

Comment 2 sounds like a good solution to me, whose only potential downside is implementation complexity, so in the face of real threats (I would like to read the actual paper), it seems like something worth exploring - in theory :)

Comment 9

[Tanvi Vyas[:tanvi]]

I first heard about the paper a year ago from one of the writers who posted to dev-security (http://www.mail-archive.com/[e-mail]/msg02803.html).  I can't seem to find it on the web, so I will follow up with them to see if it has been published or if they can share the most recent copy.

Comment 10

[Tanvi Vyas[:tanvi]]

Attachment: Automated Password Extraction Attack Paper

Here is the paper that describes the attack.

Comment 11

[Daniel Veditz [:dveditz]]

The evidence suggests sec-high overrates the bug: it's public, featured in talks, and yet little evidence of actual exploitation. And long know: see bug 534541, bug 359675, and older bugs. Don't get me wrong: I hate our implementation and counsel people not to use our password manager because it's unsafe unless you set a hidden pref, but we have not treated this as a sec-high bug and it has not been exploited like a sec-high bug.

Comment 12

[Robert Kaiser]

I think we really should do something here to require some user-interaction to fill in the password. We could team that up with making multiple stored username/password pairs more, see bug 376668 as that needs some UX rework anyhow.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

I think we're not going to fix this bug as summarized, because it leads to confusingly-inconsistent behavior and generally poor UX (our interaction-required filling flow isn't particularly discoverable).

bug 534541 remains open to track the general problem, and I think bug 653132 is a more promising approach to addressing it.