46590 - Warn users at submit time about insecure/HTTP form submissions

Status: RESOLVED WONTFIX

(Toolkit :: Form Manager, enhancement)

Description

[Ian Tommins ('thelem')]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m17) Gecko/20000726
BuildID:    2000072608

When you are submitting an insecure form which contains what appears to be a
credit card number (ie, all numbers & spaces, 10-20 numbers unless there is a
standard length) an confirm box should be shown containing something like:

"You appear to be submitting credit card information. This is an insecure
connection, and there is therefore a risk that this information could be
intercepted. It is recommended you cancel.
[Continue] [Cancel - default]"

Reproducible: Always
Steps to Reproduce:
1.Go to website with insecure credit card form
2.insert details.
3.press submit

Actual Results:  Form was submitted no problem

Expected Results:  Alert shown warning me I was submitting credit card
informating insecurely.

Comment 1

[Kevin McCluskey (gone)]

Triaging rods bug list.
Eric, do you know who is in charge of bringing up security warning dialogs?

Comment 2

[Eric Pollmann]

The insecure form submit warning dialog has been implemented and is working in
nearly all cases. If you have a specific URL that is failing, can you please
attach it to this bug report?  Thanks!  (Make sure you're running M17 or a
really recent nightly build to see this feature)

Comment 3

[Ian Tommins ('thelem')]

If I understand correctly you are saying that if _any_ information being 
submitted over an insecure form you will get an aleat. Because of the number of 
insecure forms around most people turn these off.

My suggestion would notice a credit card number and alert them if it is being 
transposted insecurely - it would be seperate from the above dialog. It is very 
easy to forget to look for a secure connection, an alert like this would help.

Tested 26/07/2000 build and there were no alerts (I think I disabled them).

Comment 4

[Eric Pollmann]

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.

Comment 5

[Vladimir Ermakov]

Updating QA contact.

Comment 6

[Ian Tommins ('thelem')]

Jogging bug for inclusion in Mozilla 1.0
Perhaps this should be implemented in JavaScript?

Comment 7

[Eric Pollmann]

This is an RFE, but CC'ing people who have implemented similar things and might
be interested in this suggestion.  (This could be implemented as an extension
like wallet or the psm-glue warning dialog, but would be significantly simpler)

Comment 8

[Stephen P. Morse]

I'm personally against such a thing.  You would be using an heuristic to 
determine if it is a credit card number and are bound to give bogus warnings in 
some cases.  I, as a user, turned off these warnings because I was tired of 
seeing them and now you are throwing them back at me.  If such a thing were 
implemented, at the very least it should be under control of a pref and that 
pref should be off by default.

Furthermore, who's to say what a particular user considers sensitive.  Do we 
want to try to detect social security numbers as well?  What about telephone 
numbers?  Frequent flyer numbers?

(BTW, if you really want to test a field for a credit card number, there is an 
algorithm for determining valid numbers.  So you could improve the heuristic 
considerably.  But I still don't recommend that you do this.)

Comment 9

[Ian Tommins ('thelem')]

Of course you would get some bugus warnings, but using the algorithm you 
mentioned should minimize these. Also, the user would be able to disable the 
warning just like they can disable the other warnings. This could be combined 
into the insecure-submit alert box somehow. This feature is designed for people 
who have turned the warnings off, if the warnings were still on then there 
wouldn't be a problem. I say it should be enabled by default.

As for what is sensitive, does it matter? Most people will consider credit card 
numbers sensitive, so it is better than what we have at the moment (ie All or 
nothing)

Comment 10

[Kevin McCluskey (gone)]

Bulk reassigning form bugs to Alex

Comment 11

[Jesse Ruderman]

See also bug 188285, Phoenix form autocomplete should not store credit card numbers.

Comment 12

[Bob Kanefsky]

I was going to suggest a similar feature, but with more specific criteria.

The feature I want is:
   - Warn if insecurely submitting a 16-digit numbers containing ____
I would then fill in several digits from my VISA card number.
This would eliminate essentially all false positives.
The default would be to match *all* form fields that contain
exactly 16 digits and no alphabetic characters.

The same could be offered for other popular credit card lengths.
There are only a few lengths in use, internationally.

Region packs should be able to add more.  For example, in the US,
a nine-digit number may be a social security number, and if it
contains the lasr (or first) four digits of my SSN, I want to
be warned if I send it unencrypted.

I'm proposing the next release after this one as a milestone;
it's been set to Future since the late 20th century.
The future is now.

Comment 13

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Your sugegstion sounds reasonable but please do NOT change the target miletone
of bugs that are not assigned to you.

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to comment #11)
> See also bug 188285, Phoenix form autocomplete should not store credit card
> numbers.

above bug was WONTFIXed in mid-2003

Comment 15

[dw]

We can do better than matching simply by length. A better test would include verifying the check digit built into the numbers, which uses the Luhn algorithm. As far as I know this has been universally used for at the least past decade. Some information is here:

 * http://www.merriampark.com/anatomycc.htm

Comment 16

[Justin Dolske [:Dolske]]

Moving to Form Mananger, since that's most likely where it should be implemented (as part of FM's usual process of watching form submissions).

Comment 17

[Dave Garrett]

Now that Luhn algorithm checking has been implemented in bug 188285 (which was un-WONTFIXed and recently FIXED), this bug should now be doable by using that to check before submission.

Comment 18

[Justin Dolske [:Dolske]]

(clearing assignment of bugs I'm no long planning to work on)

Comment 19

[Andreas van dem Helge]

The insecure form submit warning dialog has been implemented and is working in
nearly all cases. This is not a bug or defect and should be closed as INVALID.

Comment 20

[Andreas van dem Helge]

A few more points:

1) "many users will just click the ok  without thinking."
2) If for some strange reason #1 doesn't apply (it should, they are not my words but that of a longstanding community member): Users will see a security warning. They will come to expect that firefox "holds their hand" in security matters and when they do not see any warning they will incorrectly assume this implies security.

This is a very slippery slope. I agree that security is important but the best security is obtained by providing the users the tools or information needed for the security and let the user decided what choice to make. Also, showing this warning ONLY for non-SSL sights is misleading. There have been many security breaches of certificate authorities in the past and sadly it is inevitable there will be future breaches as well. Also the concept of "trust" from a CA is misleading at best. Many CA issue domain verification certificates and these are the most common. This means that even displaying a message "You are submitting a credit card number to bank-of-america-web.com, are you sure you trust bank-of-america-web.com?" can only be misleading at best. The ONLY way to avoid this is for the user to be smart about their browser/computer usage. We can try all day long to write a perfect browser but that will produce an annoying browser that is no more secure than what we have today.

Comment 21

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

I think fixing bug 188285 made fixing this unnecessary.

Comment 22

[Ian Tommins ('thelem')]

I don't want to reopen this myself because I'm the original reporter, but rather than saying that bug 188285 makes this unnecessary I think it vindicates the original suggestion. Many of counter points above are about too many false positives or missed sensitive information which apply equally to that bug.

By fixing that bug we have been made this one easier to fix with minimal false positives - i.e. in the rare case that someone does see this warning then there is a very high chance that they are risking the security of their card details. The vast majority of card forms are over SSL, so people won't get used to seeing this warning. Suitable wording and making the safe option the default will help to reduce the 'just click passed the annoying message' problem.

Comment 23

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

Sorry, I guess I closed this too hastily - not remembering them in form history is not the same as not submitting them insecurely, indeed.

Comment 24

[Matthew N. [:MattN]]

I suspect this will be wontfix in favour of bug 1349681 and bug 1371149 since it's better to provide the warning before the data is even typed (in the event that the form itself is on an insecure origin).

Comment 25

[Sergey Galich [:serg]]

Bugs mentioned by :MattN in Comment 24 are fixed. Web has evolved since this bug was opened, today sites can leak information before or even without submit events.