5

Being in the US, I have noticed that more and more companies ask to send sensitive credit card information (all information that is required to make a transaction) over a plain email. I believe that this is a security threat or at least a bad practice.

My question is whether it violates any of the standards (like PCI DSS) and how should one handle such requests?

Salvador Dali
  • 1,745
  • 1
  • 19
  • 32
  • 2
    Living in the US, I have NEVER had a company ask for credit card information over email - and I shop online frequently. Move to a different company now, and are you sure it is even a legitimate company? – cutrightjm Dec 19 '14 at 02:01
  • @ekaj From how many online shops have you bought something (5-10 different shops? In which case it does not really matters how regularly do you shop). I also shop often, and in most of the time there is no problems at all, but sometimes rental apartments, cars, moving services ask such information. In my case this is the 4-th time in 1 year period that I have encountered this, and the company is pretty legit. – Salvador Dali Dec 19 '14 at 02:49
  • 1
    The famous Resorts World Sentosa in Singapore requires you to send name, credit card number and expiration date over email. This, in 2017. Mind boggling. – Dan Dascalescu Dec 31 '16 at 15:12

2 Answers2

12

Yes, PCI DSS requirement 4.2:

Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

Unless the email is somehow encrypted, you are not allowed to use it to send cardholder data.

John Downey
  • 1,915
  • 13
  • 12
  • 1
    Actually, even encrypted mail are prohibited. Card info is never to be send by end-user messaging Technologies, encrypted or not does not matter. Thats why most banks and E-shops refuse to perform customer service matters over for example Facebook Chat, even if that is fully encrypted. The reason behind this is that even if the user have for example a validated S/MIME cert, you cant be sure that only the user Control the key. All secured Communication must be done with keys that are controlled by Merchant or any provider Merchant trust, which are true for SSL/TLS on merchant/provider site. – sebastian nielsen Dec 19 '14 at 12:30
  • 2
    @sebastiannielsen you might want to go back and read the DSS again. While I agree with your argument, it specifically says in the guidance column for requirement 4.2: E-mail, instant messaging, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN **unless they are configured to provide strong encryption.** – John Downey Dec 20 '14 at 03:04
2

In practice, it violates the DSS. In theory, it could possibly not, but that's pedantry rather than reality.

DSS Requirements 3.4 ([Encrypt] PAN data in storage) and 4.1 (Encrypt PAN data across public networks) are generally violated by SMTP mail. Each mail hop is a store-and-forward gateway that writes mail to disk even if only temporarily; unless it's encrypted, that's a 3.4 violation. Each mail connection that's encrypted with TLS is okay by 4.1... but a merchant can't guarantee that your system or the systems between you and them will use TLS, so that would never pass an audit.

While it's theoretically possible to have a fully encrypted path (each mail server with encrypted disk and all network connections protected with TLS), it's unlikely and unenforceable for Internet-based email. So, no, sending card data via email violates the PCI DSS, and you should not have a merchant ask you to do it, and you should not do it if they ask you to.

(It still happens. And PCI isn't structured to make it easy for cardholders to complain about the practices of merchants they deal with. Refusing and moving on to another merchant is probably your best bet.)

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Fully encrypted e-mail path is well-known and practical, but you don't use independent encryption/decryption at each handoff to accomplish it. Instead, end-to-end encryption like S/MIME, with the sensitive information stored in the body that remains encrypted, and the servers having access only to unencrypted header information that isn't sensitive (or at least, isn't PAN). The problem is, it only works after the sender and the recipient exchange public keys. – Ben Voigt Jan 27 '17 at 18:57
  • @BenVoigt, good point, but I read the OP ("more and more companies ask to send sensitive credit card information") as describing the sort of one-to-many relationship for which exchanging public keys is prohibitively impractical. – gowenfawr Jan 27 '17 at 19:22