Send credit card info by email from HTTPS and SMTP on SSL

Question

A client asked me to receive credit card info of his costumers by email. I know that is a very very not secure way ... But if the page with the input form is on HTTPS, and then i use a smtp (like mandrill) that use a SSL/TLS ... the email can be sniffed from someone?

Edit:

Using an encryption system like http://www.sendinc.com/ ( with their api ) could be a solution?

Answer 1

I would not trust credit card details to be sent out over email unencrypted, and while I am not an expert in PCI, I believe this violates PCI's requirements to protect cardholder data. HTTPS merely encrypts data transfer between the web browser and the web server over the network. If your email client is set up to use SMTP with SSL, that only encrypts data transfer between your email client and your email domain (e.g., if your address is gmail.com its encrypted while being sent to gmail's servers, but then gmail can fully read your data). Your mail server may route your plaintext email to many other servers (who would be able to read that information), even going over unencrypted networks if necessary.

Also again, I wouldn't trust PCI data with a company like http://www.sendinc.com/. They say they randomly generate a decryption key, which they will send to you, and also say they will not keep their own copy of that key. That last part relies on you trusting them not to keep a copy of your key or plaintext message, and I simply would not trust them to do so without an explicit business agreement that holds them liable to any flaws in their implementation setup that allows any malicious admin (or hacker) at their end to steal your data. If you need to send sensitive data over email, I would save it into a file and encrypt that file somehow locally (on the same computer) and then send the encrypted file to the client, and on a separate secure channel give the client the passphrase/key to decrypt it.

If this needs to be done infrequently, maybe something simple like install GPG in a linux/unix environment (like Mac OS X) and use gpg -c sensitive_file.txt, which will prompt you for a passphrase, and create an encrypted file sensitive_file.txt.gpg which you can then send for the other party to decrypt (gpg -d sensitive_file.txt.gpg) with a passphrase you've shared in person or through a non-eavesdroppable channel. Otherwise, you both should set up a public/private keys that you each trust, and then can set up encrypted email clients with PGP or S/MIME. This is a little bit more work, but most modern email clients support some form of email encryption.

PS: This request seems very strange. Are you sure you aren't being socially engineered by someone trying to steal credit card information? Make sure this is really your client, not someone posing as the client (say after getting their login credentials/email account password in any of a variety of ways) who is now trying to get you to give away credit card information in a phishing attempt.

Answer 2

I'm guessing he wants to use some kind of PDQ machine he already has to process the card details, rather than set up a separate internet merchant account?

Regardless of whether or not that would be secure, depending on the country he's in it's almost certainly illegal and/or against the payment processors terms and conditions. I would highly discourage it, in fact I'd personally refuse to implement such a system.

It's not just the transfer of the details that you need to worry about, it's also how they're stored when they reach their destination. Read up on https://www.pcisecuritystandards.org/merchants/ for more information.

(Sorry for not actually answering your question, but I really dont think this is even an option you should be considering.)