Open Bug 545595 Opened 10 years ago Updated 3 years ago

Warn the user when they are about to send a credit card number over non-SSL

Categories

(Firefox :: Security, enhancement)

enhancement
Not set

Tracking

()

People

(Reporter: thorsten.sick, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: uiwanted)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7

When the user enters a credit card number and is about to send it over a non-secured connection (encryption and authentication) he should be warned.

There is a test to identify valid credit card numbers. This can be used.

I fear this feature will alert a bit to often, because lots of small shops will not use any encryption. In this case, the user must be able to switch it off/whitelist the shop.

Reproducible: Always
See bug 188285, although that's about the storing of the information (both SSL and non-SSL). But a SSL connection is not a sign that the website should be trusted. I would prefer a warning for any number that might be a credit card number over any type of connection (would also work if you didn't store it in for autocomplete).
(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!)

Recommendation:
Add a warning for users (modal dialog works) when they are about to submit a credit card number over an HTTP connection.
"You are about to send what looks like a credit card number of a non-secure connection. Are you sure you want to do this?"
Blocks: cuts-control
I love that we are going through the paper cuts and getting recommendations together - but I don't think that a modal dialog is the path to winning here. I'd suggest walking it through with Faaborg, who's done a lot of work on our various user alert mechanisms over the past few releases, largely around getting *rid* of modal dialogs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: uiwanted
Tanvi, is this something that could be done along with the work that was completed to warn users before sending passwords over cleartext?
Flags: needinfo?(tanvi)
Summary: Warn the user when he is about to send a credit card number over non-SSL → Warn the user when they are about to send a credit card number over non-SSL
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)
> Tanvi, is this something that could be done along with the work that was
> completed to warn users before sending passwords over cleartext?

This would be a good extension to warning users about passwords over HTTP.  But it is a bit complicated... 

How do we determine that the form has a credit card field?
* What if it is some other, not so important or private 16 digit number?  We could send it through the same checksum algorithm used for credit cards to help guess.
* Some credit card numbers are not 16 digits.  Amex comes to mind with 15 digits; not sure if there are others.
* request Autocomplete may be able to help us with this.

Once the the user enters their credit card information, it is too late.
* We likely won't know that a field is asking for a credit card number until after the user enters the credit card number and we compute the checksum.  At that point, the user has already entered their credit card data on an HTTP page.  A MITM attacker can steal the number in many ways, even if the user doesn't hit submit (inject javascript to copy the field and send it to attackers server, keystroke logger, etc).
* If the credit card field is requested over an HTTPS page and sent over HTTP, we already show a warning like this https://people.mozilla.org/~tvyas/HTTPS-to-HTTP-post.jpg.  This is true for any form data sent from HTTPS to HTTP.
* We could show a warning when credit card numbers retrieved over HTTP are posted to HTTP.  Even though the credit card number could have already been stolen by a MITM, lets assume it wasn't.  By showing the HTTP post warning, we are saving the user from having their credit card sent in the clear all the way from their computer to the destination server.

We should see how insecure passwords goes first
* Since password fields are a little bit easier to identify, we should try and get the insecure password feature to release (meta bug 1217142) and see how it goes before taking on credit card numbers.

Thoughts and ideas on how we can flag unencrypted credit card numbers are welcome!
Flags: needinfo?(tanvi)
That was a great summary. I like doing the checksum validation and warning users who entered the data on an HTTP page even though it may have already been stolen.

Users could be reminded to monitor their credit card transactions.

We could do some text like "It looks like a credit card number has been entered on an unsecure connection. This number may have already been submitted or intercepted by a third-party. You may want to monitor your credit card transactions in the future."
Adding Aislinn.  Aislinn, do you want to try and extend the insecure password warning to credit cards?  We could do a checksum to try and determine if the number entered is a credit card, and if it is, display warning to the user upon submit?  And/or change the iconography in the URL bar even before the user has finished filling out the form or hit submit?
Flags: needinfo?(agrigas)
(In reply to Tanvi Vyas [:tanvi] from comment #7)
> Adding Aislinn.  Aislinn, do you want to try and extend the insecure
> password warning to credit cards?  We could do a checksum to try and
> determine if the number entered is a credit card, and if it is, display
> warning to the user upon submit?  And/or change the iconography in the URL
> bar even before the user has finished filling out the form or hit submit?

I think the best place for the user to see this type of warning information is contextually and not in the url bar unless it opens a doorhanger with some type of notification/explanation. Even in that case, if someone doesn't have intent to enter their CC# it is irrelevant.

If we can do any type of contextual feedback on focus of the CC field, that seems most useful. If we can't than I don't think a URL bar icon will be discoverable and not worth the effort IMO.
Flags: needinfo?(agrigas)
You need to log in before you can comment on or make changes to this bug.