31

We all know not to do it, but someone emailed my credit card number and cvv code to my gmail.

I'm wondering if the risk is so low I don't have to call to cancel my card.

The email is sent from a reputable ISP's email account, via its ADSL dialup (the ISP is the biggest in the country) to my gmail address. Is it safe to assume that the ISP, connected to the backbone, would deliver the email to gmail server without going through unsecured pc? So I don't need to cancel my card?

Anddd
  • 311
  • 1
  • 3
  • 3
  • This someone is my colleague who is buying something on my behalf. So email folder and account security are not an issue. I'm more worried about it during transit. – Anddd Oct 05 '11 at 15:37
  • It is certainly a risk, but this incident made me rethink that maybe the risk is much lower than we perceive. Perhaps it is too easy to cancel and replace a credit card we automatic think canceling it is the only right thing to do. – Anddd Oct 05 '11 at 15:40
  • 1
    Send CCN by e-mail and CCV by SMS or vice versa? Well, if encryption is no-go. – StupidOne Oct 05 '11 at 16:07
  • check the header to see through which servers the mail is sent and whether a secure line was used. – ratchet freak Oct 05 '11 at 18:31
  • 8
    Insecure protocols don't magically become secure. If it was insecure before, it is still insecure now. – Piskvor left the building Oct 06 '11 at 07:34

7 Answers7

40

Let's see:

Even if what you say is right and ISP is solid as rock

  1. Do you trust this "someone"? If answer is no - cancel the credit card in any case.

  2. Your credit card number + CVV is now in this person "Sent" folder, if his mailbox will be hacked attacker will have you CC.

  3. Your credit card info will be stored forever on Google servers

  4. I would cancel it
M'vy
  • 13,053
  • 3
  • 48
  • 69
AaronS
  • 2,575
  • 5
  • 22
  • 26
  • 4
    +1 for the sent items folder. An attacker can easily perform a search for numbers that resemble CC conventions. – Wesley Oct 06 '11 at 17:32
  • 5
    Trusting this person also means trusting them to secure their computer against malware. I.e. trust nobody :) – Stefano Palazzo Oct 10 '11 at 17:51
  • +1 for the google servers. Though it is not feasible/possible to get it from there.. what happens to the copy of the mail when it is deleted from our boxes(trash includes)? though it only makes sense to delete it from the servers, i just want to make sure! – Karthik Apr 24 '12 at 08:17
  • Who knows? Even if they say they delete it, can you verify that? Even if they've deleted it from their live server, what about backups? – Stephen Touset Apr 15 '13 at 19:01
30

Email is not a secure way to share credit card numbers

The method you describe is not secure for a variety of reasons. These include:

Sending numbers in plain text is not secure

The technique you described could have involved you sending your card numbers in plain text (the act of sending the e-mail from the computer to the ISP). This is not secure. It could have been picked up in a variety of ways

E-mails are persisted in multiple places

That credit card number can now exist in multiple places

  • In the 'sent' folder of the computer from which it was sent
  • On the ISPs servers
  • In the Gmail account

Now that is just 3 places it could be stored, when you take in to account backups there could already be many, many copies of your numbers spread about across the world.

Andy Smith
  • 2,762
  • 1
  • 19
  • 24
  • Absolutely! There will be a copy on every email server involved in the process, at least until it gets overwritten with new email data. All it takes is for *one* of them to be malevolent. (You can read your email headers to see a list of servers involved.) – jpaugh Jan 27 '17 at 18:39
13

I think the above answers are correct and sending credit card details over email is insecure. However as you were specifically concerned about interception in transit rather than the various storage points mentioned in the other answers, it is at least worth considering a contrarian viewpoint:

Consider the attack tree:

Fixed networks (inside corporate):

  • An attacker would have to breach physical access controls (or be a photocopy repairman) or be an insider
  • Get past an NAC (but most companies don't have this) or have a workstation
  • In packed switched networks (all modern corporations) you just don't have access to a lot of broadcast traffic
  • So you have to to get access to a router or switch, assuming you are not a network admin this means exploiting a security misconfiguration or vulnerability (fine no problems metasploit exists, most organizations suck at patching especially network devices) but lets say you listen to Cisco/Juniper etc and patch every 3 months (at least the really bad stuff) or so and you at least authenticate everything to a RAS server
  • Even if you can get access, ARP poisoning, DNS cache poisoning whatever, then you have the next problem: volume. There is a hell of a lot of data that goes access a major router or key switch. Many are gigabit enabled now and that means drinking from a firehose. Even with a legit network DLP monitor you need a high performance packet reassembler, good hardware and software and then the ability do effective pattern matching. So getting that CEO's email very tough, getting the odd password probably not so bad
  • This data is also transient - once the packets are gone they are gone (although admin logins can happen often) but there is a limited window of opportunity
  • Alternatively you could do what I talked about earlier which is put the sniffer on the box you want to monitor, again though same problem assuming reasonable access which is a misconfig or security vulnerability, or lack of anti-malware controls. Also with the first two it is a lot more targeted attack

Public networks:

  • Seems like a lot easier target - you can no longer be comfortable about access controls of intermediate boxes or network devices
  • But lets look at something like email - most Mail Transfer Agents (MTA)'s including big ones like Google now use optimistic TLS which means, the majority of your email which arguably holds a your most sensitive info, is likely to be encrypted in transit without you having to do anything more
  • Even shared MPLS networks have VLAN tagging
  • Again you have the firehose problem but a million times worse and the transient information page
  • See how many actual exploited loss incidents you find on datalossdb.org or web app sec incidents on interception of data in transit

Wireless network:

  • Corporate: WPA2 is a de-facto standard, its not perfect but you are getting encryption without doing anything more
  • Home/Starbucks etc: This is a legitimate risk in fact the best and only example that OWASP gives for no. 10 lack of transport encryption is interception on an unsecured home wireless network - hell even Google cars on streetview can do it. But even here most/all corporates that provide remote access provides a VPN so do you need anything more?

Full blog post: http://www.rakkhis.com/2010/08/why-ssl-is-just-not-that-important.html

You should probably still cancel the card, but considering other controls such as the limit on the card, if you have 3D secure (e.g. verified by visa) enabled, you monitor your statements, your banks fraud detection systems; if these make the risk within your risk appetitite you may decide the risk of interception in transit or storage is low enough for you to accept.

Rakkhi
  • 5,803
  • 1
  • 23
  • 47
  • 1
    Correction to "which means the majority of your email (...) is encrypted in transit" - I'd say "which means that the majority of your e-mail *could* be encrypted in transit - maybe it is, maybe not". – Piskvor left the building Oct 06 '11 at 07:22
  • @Piskvor ok fair point, if the MTA does not support TLS is will not be encrypted, we investigated about 1000 and found only 1 that did not support opportunistic TLS. Updated wording to likely to be. – Rakkhi Oct 06 '11 at 22:30
  • Fair point, good to know, and it does reduce the risks somewhat. Thanks for sharing that :) – Piskvor left the building Oct 11 '11 at 13:18
  • About the WPA2 WiFi network, just keep present that if WPS is enabled on their access point, then the WPA2 network is substantially easily crackable, see here for more information http://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/ – Max May 09 '12 at 19:02
7

Google's mail servers do support AUTH TLS as preferred so there is a good chance that your credit card was in transit encrypted. Again, now you have 'track 2' data stored that shouldn't be, namely your CVV.

If this credit card is actually a debit card, I would most certainly cancel right away. Credit cards have pretty good protection/hassle-free about fraudulent activity. I certainly would feel uneasy, and you too probably feel uneasy as you wouldn't have posted the question, so I would probably just get the credit card re-issued.

If that "someone" is a merchant, you may not want to do business with them if they are so cavalier with your cardholder data. If that person is someone trusted then you need to evaluate the reason why your card was transmitted to you in an e-mail and fix that process.

M15K
  • 1,182
  • 6
  • 7
6

I would still advise you to replace your card to be on the safe side, but if it was MY card, I wouldn't worry about it.

You obviously shouldn't increase the risk to your credit card unnecessarily, but with all that being said, do you replace your card every time you pay in a restaurant and the waiter goes away with your card and brings it back?

When you consider the added risk to your card in this particular case you described, I think it's worth considering other risks to your card during its usage (usually over a span of a few years). Other scenarios of card usage typically include:

  • Restaurants/Bars - have you never paid with a credit card before? How easy it is to write down or memorize your card details
  • Call Centres - have you never given your card details over the phone?
  • Shops (do you ever notice how many shops have CCTV cameras?)
  • Community centres / gyms where you are a member
  • Of course so many websites that you don't have any way to know who has access to those details

There are a lot of places where someone can get both your card number and CVV + expiry date and in many of those situations they might already know something about you like your full name and address and maybe even your date of birth.

So comparing those risks, which pretty much anybody with a credit card has to take, to this one email (and good overview from @Rakkhi about what it means to be able to grab this email): I think the other leak scenarios are far more likely than from Gmail or from someone sniffing the network.

Yoav Aner
  • 5,329
  • 3
  • 25
  • 37
2

This is an old question, but I think you should cancel the card.

Everyone talked about the likelihood of someone intercepting the email in transit. That is... so very unlikely unless your local network is already being MiTMed.

The HUGE exposure surface is that other person's email account with their undoubtedly crappy password or poor browsing habits / virus issues; your CC is sitting in their sent folder and it is super easy to automatically search for that information and mine it via botnet. Your account is a problem too, but at least you have control. You have no control over the other account.

Josh
  • 21
  • 1
  • Plus if it's like half the people I work with, it sits in the trash forever just waiting for some crimeware to scrape the information, along with all the account logins that have never seen a password change. Ever seen an Outlook mailbox with 1.5G of trash? Heh. – Fiasco Labs Oct 31 '15 at 06:30
1

Why did this party have your pan and cvv?

If you provided it to them then they should be pci-dss compliant, and from my limited knowledge of this, it does not allow pan to be sent or stored unencrypted. CVV data must not be stored.

While, as others have said, a lot of SMTP traffic may be encrypted, it is very difficult to determine in advance if this is the case for a given message, but its virtually impossible to know whether an email will be stored in a compliant manner by a third party.

symcbean
  • 18,418
  • 40
  • 74