Sending sensitive information over email?

August 31, 2007 12:59 PM

Is there any simple way to encrypt the information in a web form and deliver it via email?

I'm working on a project for a client requiring that credit card information be delivered over email. They will then process it in line with orders taken by mail and by phone.

I know very little about email security, but I do know it's probably a bad idea to send it in plain text.

My thought is to send the form information to a PHP script that creates either an encrypted PDF or an encrypted zip archive containing a plain text file and emails it to my client. But when the info moved from the form to the PHP script, it's out there for everyone to see, right? Would loading the PHP script in an iframe help? Is this something that needs to be done over https? Encrypted email? How hard would it be for a rather tech-unsavvy person to set that up?

I'm really just lookin' for ideas at this point. Thanks!

posted by Plug Dub In to computers & internet (16 comments total)

Is your client a card merchant? Because most of these have pretty severe limitations on how the data can be handled. Mastercard, for instance, requires you meet the PCI Data Security Standard, and will fine you if you don't.

They don't rule out email, but have hefty requirements on how you handle the keys and encryption.
posted by bonaldi at 1:15 PM on August 31, 2007

The standard
posted by bonaldi at 1:16 PM on August 31, 2007

Yep, learn about PCI. I'm embroiled in a PCI compliance project at my job that is taking the better part of 2 quarters to implement. Their best bet if they are a small merchant is to contract out with a 3rd party vendor who is set up to do PCI compliant CC processing, and will just give them a GUID for each transation to hook into their online ordering system, so the merchant does not have any CC information.
posted by matildaben at 1:32 PM on August 31, 2007

There is no way you (or your client) will be able to send credit card info via email and retain their banking/credit account. It's a non-starter, a deal-breaker, and user-hostile.
posted by rhizome at 1:36 PM on August 31, 2007

On the upside, you'll be able to get a high margin on your time if you use whatever script you can cook up in 5min, since the site will not be taking in very many CC#'s before shutting down their cc acceptance.
posted by rhizome at 1:38 PM on August 31, 2007

To protect the credit card information on its way from the user's browser to your server, you will need SSL (https).

Once it's reached your server, sending it via unencrypted email is a bad idea-- it's sort of like putting a strong lock on your front door and nothing on the back door.

If the client uses Outlook you can send encrypted messages to them, but first they will need a digital id.

Once they've got one, you can send encrypted messages to them using their public key.

It would be better for the client to get a merchant account and process transactions directly with authorize.net so they don't need to retain the card #'s.

If that's not an option, what about a system that stores the orders online via a password protected admin area and emails the client when a new order arrives? (e.g., ShopSite)
posted by justkevin at 1:44 PM on August 31, 2007

1. This is something that needs to be done over HTTPS. An iframe does absolutely nothing, it's just like any other page.

2. An encrypted PDF is not a horrible idea.

It isn't actually your responsibility to adhere to the PCI standard(s), it's the company that is taking in the money. You should let them know of relevant official standards and inform them of the risks of one approach or the other. Ensure in any contracts that you are not liable for such things once you're done.

Your question sounds pretty informal, so I have a feeling you're not doing this for a giant corporation or anything. HTTPS is good, though a minor pain to set up; you'll need a key from a Certificate Authority, like VeriSign/Thawte, GeoTrust, etc., and specific details vary depending on your webserver (Apache, IIS, etc.)

If you're "tech-unsavvy", you might want to think about whether you really should be messing with credit card data. Not an insult, just a thing to think about – being liable for a bunch of missing numbers can be pretty bad.
posted by blacklite at 1:55 PM on August 31, 2007

Nthing HTTPS as the right way to get the CC# from the user's browser to your web server. You could, in theory, apply strong encryption in the browser using JavaScript, but I really don't want to think about trying to get that right.

In addition, many browsers "know" that https pages tend to contain sensitive material, and will be more careful about caching them, storing form values, and so on.

Getting the CC# from the web server to the human who's processing orders depends more on the particular details of your client's setup. Have you considered having another web page— visible only to the people at the company— containing the secure details of each submitted order? The emails then could contain the less-sensitive info ("Bob Jones orders 1 unit of foo, 3 units of bar, ship to XXXYYYZZZ") and an https: link to a page showing the full details of the submission including CC#, billing info, email address, etc. (Blah blah strong authentication for access to that page of course.)

You should make sure that you comply with PCI if you need to, and it's probably worth a read-through even if you don't need to comply, but also remember that most such standards are only half-rational. It'll have requirements that do no good and lacunae that would allow you to build a conforming yet insecure system.
posted by hattifattener at 2:53 PM on August 31, 2007

The easiest thing is to use a credit-card processing company like PayPal (possibly the worst of the bunch), 2Checkout, or similar. Your shopping cart gathers all the info except billing stuff, then send them on to the processor, which just takes the payment. Your client will get email notifying them that a purchase has been made so they can fulfill the order, and the money collected by the processing system can be deposited directly into their bank account.
posted by CaptApollo at 2:53 PM on August 31, 2007

A few years ago at another job i did this sort of thing for a client who was used to getting CC#s via email and was reluctant to change the way he handled them. I insisted that the emails at the least, be encrypted, and the general way we handled it was:

1. HTTPS to CC submission page.
2. CC gets encrypted with a public key server-side without being stored anywhere.
3. email is sent to the client, who has the private key and can decrypt the email.

Now, there are DEFINITELY better ways of doing this, but if for some reason, it's not possible, you can do it this way. For step #2 i think I was using an ASP module, but you may be able to find a php library to handle the encryption for you.

I'm sure there's probably some fine print about how you're supposed to handle credit cards for people with merchant accounts, but this guy had been doing this, UNENCRYPTED, for years, so if you're dealing with a small fry and he insists on it, well, he'll probably be ok (also, not really your problem). You will, however, feel dumb for working on something so ridiculous. Try your best to sell them on the benefits of having a merchant account that can handle all this for them.
posted by fishfucker at 4:45 PM on August 31, 2007

ok, on re-read, i see it's a client requirement. to be more specific:

My thought is to send the form information to a PHP script that creates either an encrypted PDF or an encrypted zip archive containing a plain text file and emails it to my client.

you probably want to use S/MIME encryption. Picking up the right library will handle all the attachment stuff for you; once the client decrypts it'll be just like a regular email. Putting it in a PDF or a ZIP before encrypting is an extra step -- if you're thinking of PDF or ZIP password protection, then stop; they don't provide strong encryption.

But when the info moved from the form to the PHP script, it's out there for everyone to see, right?

Use https. You will need a properly set up certificate, which can be a bit of a pain in the ass if you're trying to DIY and you've never done it before.

Would loading the PHP script in an iframe help?

no.

Is this something that needs to be done over https?

most definitely yes.

Encrypted email? How hard would it be for a rather tech-unsavvy person to set that up?

you need someone with at least a passing familiarity with a scripting language.

However, it looks like MivaMerchant can send PGP encrypted emails. You may be able to find a host that already has this software installed and offers the secure mail option.
posted by fishfucker at 4:56 PM on August 31, 2007

Thank you all for the information and suggestions. I'm beginning to think this is a bit outside my capabilities. We're still in the talking stages of the project, so maybe we can convince the client to go with an outside credit card processor. We shall see.
posted by Plug Dub In at 7:17 PM on August 31, 2007

A little late here, as noted, you really want to source this to a company that will certify it as PCI compliant and indemnify you to that effect.

There are any number of organizations who do this or who can help you do this as their core competancy and have an established history of working with you to identify the right solution, I work for one of the larger ones.

The trouble with encrypted mail is the users and lack of control of the data after it leaves your system. The better solution is to send the users a mail and provide them with instructions that log them in to a system of your own design (or any of the commercial solutions; ie encryption via appliance(ingrian or the like) in to oracle, oracle encryption itself/etc/etc/etc) via https.

This has a number of benefits, you can insure the overall security of your platform, and correct any shortfalls as they are identified or enhance security without exposing the enhancements to the users. You can swap out user authentication mechanisms as the technology evolves. Users are familiar with following links in web browsers and email, it's the standard they interoperate with now. The methodology for the above is tested in the marketplace and is vetted routinely. Encryption of email, issues aside will likely not have been vetted to the extent the SSL/TLS and other encryption/transport schemes have been, PGP/GPG aside.

Please talk to a professional who is thoroughly familiar with PCI requirements and best of luck.
posted by iamabot at 1:12 AM on September 1, 2007

Although it's a bad idea to email credit card details, an awful lot of sites do it and get away with it; even some big organisations resort to email to get sensitive data from the web (as their IT depts are too slow/obstructive/incompetent to set up better systems) and have people copying and pasting into their internal systems. If customers knew how much of that kind of thing still goes on they'd be horrified.

One option to consider is to store the details encrypted on the server, and have the client periodically download and decrypt data using a simple desktop app. The decryption key wouldn't be on the server, and the data would be removed after a successful download.
But yeah, ideally you'll want to talk the client into using a proper online payment provider.
posted by malevolent at 1:47 AM on September 1, 2007

A friend implemented something like this for a client invoking GPG from PHP to encrypt the email to be sent. I'll ask for details.
posted by kableh at 6:20 AM on September 1, 2007

Soupermail is a free CGI program you can fairly easily add to a site to do exactly what you want: encrypt a form and send the encrypted result via email, to a recipient to decrypt with pgp.

In the case of a non-profit I help, Soupermail encrypts the credit card info entered on an https form, and the treasurer decrypts the emailed info and processes the card purchase by hand. Very basic but fine for small numbers of transactions.
posted by anadem at 9:09 AM on September 1, 2007 [1 favorite]