Closed Bug 261294 Opened 18 years ago Closed 7 years ago

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

Categories

(Toolkit :: Password Manager, enhancement, P1)

enhancement
Points:
5

Tracking

()

RESOLVED DUPLICATE of bug 748193

People

(Reporter: felipe, Assigned: agrigas)

References

()

Details

Attachments

(2 files)

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
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/
I still believe this should be implemented....is more information necessary?
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.
Assignee: bugs → nobody
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Summary: Moz should separate "unsecure form transmission" from "unsecure password transmission". → Option to warn about insecure password submission (but not all insecure form submission)
(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.
(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".
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.
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 *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.

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.
(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.

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.  
Oh, and it would be nice to add exceptions for intranet sites where you may not have ssl, but are on the same LAN.
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.
Attached file 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.
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.
 I like it.  Although it changed the box shading too.
Product: Firefox → Toolkit
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)
(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.
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.
Component: Form Manager → Password Manager
QA Contact: form.manager → password.manager
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.
Attachment #412473 - Flags: ui-review?(shaver)
Duplicate of this bug: 476797
Attachment #412473 - Flags: ui-review?(shaver) → ui-review?(johnath)
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.
>> doh, should have read more "The patch does not cover the broken-chain-of-trust case (i.e. HTTP document to HHTPS target)."
(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'
I agree with miketosh.  Catching a few problem cases is better than not catching any.
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 ux-review@mozilla.com alias
Attachment #412473 - Flags: ui-review?(johnath) → ui-review?(ux-review)
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 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.
Attachment #412473 - Flags: ui-review?(ux-review)
Duplicate of this bug: 909079
Is any progress being made with this issue?  I think it would be awesome :)
Duplicate of this bug: 1169984
Blocks: 748193
Flags: firefox-backlog?
QA Contact: agrigas
Whiteboard: [fxprivacy]
Summary: Option to warn about insecure password submission (but not all insecure form submission) → Provide feedback on password field when insecure password submission occurs (but not all insecure form submission)
Assignee: nobody → agrigas
Status: NEW → ASSIGNED
Iteration: --- → 41.2 - Jun 8
Flags: qe-verify-
Flags: firefox-backlog?
Flags: firefox-backlog+
Whiteboard: [fxprivacy] → [fxprivacy] [ux]
Points: --- → 5
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).
QA Contact: agrigas
Blocks: 1170621
Priority: -- → P1
(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.
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
Rank: 4
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1135766
Iteration: 41.2 - Jun 8 → ---
This is the implementation bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Whiteboard: [fxprivacy] [ux]
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 748193
You need to log in before you can comment on or make changes to this bug.