261294 - Provide feedback on password field when insecure password submission occurs (but not all insecure form submission)

Status: RESOLVED DUPLICATE of bug 748193

(Toolkit :: Password Manager, enhancement, P1)

Description

[Felipe]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

Right now Moz warns the user before sending unencrypted information via a form
submission; it does not examine what that information is. So if I go to Google
with a default Mozilla build, type in "radio", I get a warning. Like most users,
I find this annoying, and so I disable it and go on with my life.

However, I *would*, and perhaps many other users would as well, appreciate a
special kind of warning that is triggered when submitting data from a
password-type <input> element. Generally the most sensitive information in a
form submission is that which is entered into a password field; hence, it makes
sense to have the form submission warning have a "special case" for unencrypted
password submissions.

Reproducible: Always
Steps to Reproduce:
n/a - feature request

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Felipe]

I still believe this should be implemented....is more information necessary?

Comment 3

[Clement Cherlin]

The suggestion makes sense to me.  I don't give a hoot who watches my Google searches, but I'd like to be reminded by my browser when I enter my webmail account password on the regular http login page instead of the https one.

Comment 4

[Jesse Ruderman]

This makes sense to me, too.  The option to warn about all insecure form submissions is kinda useless because it shows up on so many form submissions.

Comment 5

[Johnathan Nightingale [:johnath]]

(In reply to comment #4)
> This makes sense to me, too.  The option to warn about all insecure form
> submissions is kinda useless because it shows up on so many form submissions.

fwiw, bug 341472 disabled this notification by default.  The dialog about submitting insecure content from a secure site, is, of course, still there.  That doesn't invalidate this bug, of course, but it changes the motivation slightly, since the original offending dialog is now disabled by default.

Comment 6

[Felipe]

(In reply to comment #5)
> 
> fwiw, bug 341472 disabled this notification by default.  The dialog about
> submitting insecure content from a secure site, is, of course, still there. 
> That doesn't invalidate this bug, of course, but it changes the motivation
> slightly, since the original offending dialog is now disabled by default.
> 

I think the idea is that, while almost no one cares if they submit a Google search unencrypted, just about everyone would want a warning before submitting unencrypted data that was entered into an INPUT element of type "password".

Comment 7

[Mike Shaver (:shaver emeritus)]

I don't think we should warn on submit as much as put an indicator that the password field is going to go somewhere insecurely.  A little red (!) in the field might suffice -- like the "you have caps lock, btw" indicator on some operating systems.

Comment 8

[Jesse Ruderman]

Note that to be accurate, the indicator would need to appear whenever the page (or any of its ancestors, for frames) is http, regardless of where the form submits to.

Comment 9

[miketosh]

I *NEED* this feature.  

(In reply to comment #8)
> Note that to be accurate, the indicator would need to appear whenever the page
> (or any of its ancestors, for frames) is http, regardless of where the form
> submits to.
> 
I greatly disagree.  If your form is http, but the target is https, then your data will still be encrypted.  There is a concern for pages that could use JS trickery though, but that is still a problem whether this feature is implemented or not.

Comment 10

[Mike Shaver (:shaver emeritus)]

It'll be encrypted to where?  Without https, the page you think you're getting from http://mysite.com could easily be coming from http://lolipwnyou.com, and then it can submit to https://lolipwnyou.com without a warning.  You can download tools that make this clicky-click.

Comment 11

[Johnathan Nightingale [:johnath]]

(In reply to comment #9)
> I greatly disagree.  If your form is http, but the target is https, then your
> data will still be encrypted.  

Your disagreement is splitting hairs that I don't think users want split. If any content is delivered over http channels, the fact that it submits to https is nearly irrelevant, since anyone in a position to sniff the unencrypted traffic could instead be injecting their own content to steal credentials.

> There is a concern for pages that could use JS
> trickery though, but that is still a problem whether this feature is
> implemented or not.

We're not concerned with the page itself, we're concerned with attackers.  Attackers can modify http content in ways that they cannot modify https content, so I would disagree with this statement.

Comment 12

[miketosh]

I'm going to pretend I made my comments to incite comments?

:-)

However this warning comes, whether HTTP or HTTPS form, it would make for a great feature.

And I'd like to remove my 'greatly' from my previous comment.  

Comment 13

[miketosh]

Oh, and it would be nice to add exceptions for intranet sites where you may not have ssl, but are on the same LAN.

Comment 14

[Johnathan Nightingale [:johnath]]

I whipped this up as an add-on.  It turns the password field red, and supplies a tooltip in the element explaining that the submission is unsafe.

https://addons.mozilla.org/en-US/developers/details/8128

Playing with it there a little is a good way to see if it's something we want to uplift into the browser itself.

Comment 15

[Johnathan Nightingale [:johnath]]

Attachment: test extension

Attached here too, since amo is being grumpy about hosting it for reasons that may be due to cache propagation, or something else.

Comment 16

[Johnathan Nightingale [:johnath]]

And of course, once the AMO thing is sorted out, the right URL will be: 

https://addons.mozilla.org/en-US/firefox/addon/8128

Not the developers link in comment 14.

Comment 17

[miketosh]

 I like it.  Although it changed the box shading too.

Comment 18

[quantumpacket]

Is there any word on this being added as a feature? I have been using the extension and so far works great on identifying unsafe password forms. 

I think the background color should be more consistent with Larry, where on an unsafe password form it shows as gray or just no background at all, and a safe one as light blue. If you want to get even more into it you can make it light green on EV sites. 

Personally I think this is a safer way to do this since most users' eyes are on the form they are typing their info into rather than looking if the URL is https or the urlbar's colors show its safe or looking for a lock icon. People are lazy when it comes to seeing if a site's page is safe to enter info, why not make it easier? Just my 2 cents. =o)

Comment 19

[Johnathan Nightingale [:johnath]]

(In reply to comment #18)
> Is there any word on this being added as a feature? I have been using the
> extension and so far works great on identifying unsafe password forms. 
> 
> I think the background color should be more consistent with Larry, where on an
> unsafe password form it shows as gray or just no background at all, and a safe
> one as light blue. If you want to get even more into it you can make it light
> green on EV sites. 
> 
> Personally I think this is a safer way to do this since most users' eyes are on
> the form they are typing their info into rather than looking if the URL is
> https or the urlbar's colors show its safe or looking for a lock icon. People
> are lazy when it comes to seeing if a site's page is safe to enter info, why
> not make it easier? Just my 2 cents. =o)

I appreciate your suggestions, and your attention to the way users behave, where they tend to look, etc.  Understanding those things is a critical part of good design.

My concern with colouring the boxes in "affirming" or "positive" ways instead of just colouring them "negatively" is that there are many many ways a password form might be insecure behind the scenes, and we don't want to overpromise on the "this login is safe" message.  Marking the ones we *know* to be unsafe is something we can stand behind.  In the other cases, where we've left it unmarked, well, you're back to making the decision based on the other tools you have available - the site identity feedback, your history with the site, your feelings about the company that runs the site and how likely they are to treat your information securely.

We need to be very careful about being the ones saying a site is "safe" - we can't know that; they could be throwing credit reports out in a public dumpster.  Instead, I think we should give them whatever information we can really stand behind, and recognize that much as we might like to make the call here, it's not something that you can do with technology alone.

Comment 20

[quantumpacket]

Can the MUPE addon be made so it shows the password manager password prompt as having a red border/background on unsecured pages. I see it this way I go to a page that uses HTTP where password manager has a saved password, it prompts me for password and then the form fields are filled in. Since I am not on HTTPS I cannot know if the HTML contents have been tampered with and a malicious JS script has been put which could take the login info as they get filled in. By showing me the page is insecure before I typed in my password into the password manager I can choose to cancel the prompt. Correct me if I am wrong if Firefox has security in place to prevent JS from accessing form fields after password manager fills in the login info.

Comment 21

[Andreas Wuest]

Attachment: Display a security warning dialog on form POST to non-HTTPS URI, v0

Patch against trunk (changeset 81531f1b2e92).

This patch displays a security warning dialog on form POST over an insecure connection, analogously to the warning dialog that is shown when submitting any form content insecurely.

The dialog is triggered both when submitting from a HTTP document to a HTTP target (|nsSecureBrowserUIImpl::ConfirmPostToInsecure|) as well as from an HTTPS document to a HTTP target (|nsSecureBrowserUIImpl::ConfirmPostToInsecureFromSecure|).

The patch does not cover the broken-chain-of-trust case (i.e. HTTP document to HHTPS target).

The patch introduces a new interface |nsISecurityWarningDialogs2| (since |nsISecurityWarningDialogs| is frozen), in the tradition of nsISelection2 or nsIGlobalHistory2 and nsIGlobalHistory3. |nsISecurityWarningDialogs2| extends |nsISecurityWarningDialogs|. All callers that so far expected |nsISecurityWarningDialogs| are now expecting |nsISecurityWarningDialogs2|.

What is unclear to me is if we expect embedders to implement their own "@mozilla.org/nsSecurityWarningDialogs;1" component. If that would be the case, the fact that this component is now expected to implement |nsISecurityWarningDialogs2| would be a problem of course.

Note that the dialog cannot be ignored by the user via a checkbox in the dialog itself, and also not via a hidden pref. This can be added of course, although I think that it should only be controllable via a pref that is not exposed in the UI.

Although the consensus in the discussion above seems to be to use an indicator directly in the form instead of a dialog, I believe that the dialog approach is a good first approximation. It would already help users now, until a better UI experience is developed.

Comment 23

[quantumpacket]

Provided this is done only for password forms.

If you are on HTTPS and the page submit to HTTP a notice should appear.

If you are on HTTP and submit to HTTPS a notice is useless
If you are on HTTP and submit to HTTP a notice is useless

The above are useless because since the data arriving at browser is not encrypted it could be easily manipulated. An attacker could change the forms and add JavaScript that can easily do the following. Make an onsubmit for the password form where it cancels current form submission makes a new form using JS, where the password is in text field instead and then use submit() to submit the new form. This will effectively bypass any checks since no password field is being submitted anymore. Thus this should only be implemented on HTTPS forms that submit to HTTP.

Comment 24

[quantumpacket]

>> doh, should have read more "The patch does not cover the broken-chain-of-trust case (i.e. HTTP document to HHTPS target)."

Comment 25

[miketosh]

(In reply to comment #23)
> If you are on HTTP and submit to HTTP a notice is useless

I don't agree.  Sending a clear password to HTTP from HTTP is something I would like to be warned of.  This isn't preventing submission, just warning about a potential problem.  I could easily overlook a missing HTTPS protocol in the URL if the page looks correct.

Just because not all cases could be captured doesn't mean that what can be detected should be ignored.  Perhaps I'm thinking of 'Before I enter my password' and you are thinking 'After hitting submit'

Comment 26

[Mark Doliner]

I agree with miketosh.  Catching a few problem cases is better than not catching any.

Comment 27

[Johnathan Nightingale [:johnath]]

Comment on attachment 412473 [details] [diff] [review]
Display a security warning dialog on form POST to non-HTTPS URI, v0

Moving UI-review requests over to the [e-mail] alias

Comment 28

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 412473 [details] [diff] [review]
Display a security warning dialog on form POST to non-HTTPS URI, v0

It's hard for me to test this without a tryserver build.

I agree with the general principle here, but I'd have to get some real-world use in on common web sites to get a feel for how intrusive this would be. I suspect that most sites do login via unencrypted HTTP still, but we might want to do this anyway to influence security on a web-wide scale.

Ping me again when there's a way to test this via a build? A one-off binary for OS X would work fine too.

Comment 29

[Alex Limi (:limi) — Firefox UX Team]

Comment on attachment 412473 [details] [diff] [review]
Display a security warning dialog on form POST to non-HTTPS URI, v0

Clearing the review flag until I have the ability to evaluate this via a tryserver build or similar.

Comment 31

[Ben Kennish]

Is any progress being made with this issue?  I think it would be awesome :)

Comment 33

[Matthew N. [:MattN]]

Since this is an old bug with a bunch of people CC'd waiting for the fix, I think this should remain a developer bug (not only for UX).

Comment 34

[Ian Macdonald]

In any case, SSL does NOT protect passwords, because it is a form of reversible encryption. Passwords should be hashed with a non-reversible algorithm. If the host webserver has been compromised (the most prevalent scenario) then the hacker can obtain the plaintext password from an SSL submission.  

Effectively, having the browser indicate to web app  developers that using plaintext password transmission with SSL equals a secure auth system (because that makes the security warning go away) is dangerously misleading.

Comment 35

[Dave Garrett]

(In reply to Ian Macdonald from comment #34)

Please don't attempt to start a discussion on the nature of password security here. It's not helpful.

It's very simple:
passwords as a general concept -> bad
passwords transmitted in any form -> more bad
passwords stored on server without a slow hash -> negligent or malicious
passwords transmitted over cleartext protocols -> psychotic

This bug is just for ratcheting down the severity of the situation. Don't let the ideal be the enemy of improvement, and please don't attempt to use Bugzilla as a general discussion forum. :/

Comment 36

[Ian Macdonald]

Not a discussion on password security, just pointing out:

Textbooks say passwords should be hashed. 
Encryption is not hashing. 
SSL is an encryption system.
The purpose of SSL is to protect data from inquisitive carriers.  
The most common security risk is the webhost being compromised. 
SSL provides ZERO protection in such cases. 
Therefore, advice to use SSL to protect passwords is dangerously misleading.

Comment 37

[Ash Grigas]

(In reply to Matthew N. [:MattN] from comment #33)
> Since this is an old bug with a bunch of people CC'd waiting for the fix, I
> think this should remain a developer bug (not only for UX).

I'm happy to break out the UX work into its own bug. Tanvi is working on the platform part of this issue so don't want to create confusion. This ticket is just for the UX part as it stands.

Comment 38

[Tanvi Vyas[:tanvi]]

Related bugs.  These are all about adding a doorhanger, and not doing anything to the form field itself.

https://bugzilla.mozilla.org/show_bug.cgi?id=748193 - development work to notify users via a doorhangr when an HTTP page contains a login form.
https://bugzilla.mozilla.org/show_bug.cgi?id=1135766 - UX for the doorhanger
https://bugzilla.mozilla.org/show_bug.cgi?id=1135758 - icons to use for the doorhanger

Comment 40

[Matthew N. [:MattN]]

This is the implementation bug.