Can This Be Done?

[jim_bob45506]

I have a client who just signed up with TCH. She owns a small business that offers self-improvemwnt classes for a fee and wants to make on-line registration possible via her new site.

 

She would like to know if she can use the TCH shared SSL to process the charge card registration info to an email address, then use webmail to collect the registration info to manually process the charge through her business merchant account.

 

I know SSL encrypts the info between the browser and server. Will she be able to read the encrypted email info once it is on the server? How would this work best?

 

Thanks for the feedback.

[HCSuperStores]

I know the technology exist to encrypt e-mail transissions, but I've never used it nor looked into it.

 

My personal opinion is to strongly discourage my clients from ever using e-mail for secure transissions. Especially credit card information.

 

I'm curious how others feel about this and their experince. Maybe they'll change my view!

 

I hope you find your answer to this one.

[schussat]

I experimented with this for a couple of minutes. It's not hard to use gpg to encrypt the message, but that's at the command line. I tried a quick php script that would essentially run gpg and use my public key to encrypt a file, but it never seemed to actually work. The script, which I just found online, looks like this:

 

<?php

  $gpg = '/usr/bin/gpg';

  $recipient = 'email@domain.com'; // some address stored in your public keyring

  $secret_file = 'secret_file.txt';

    echo shell_exec("$gpg -e -r $recipient $secret_file");

?>

 

My guess is that the shell_exec command isn't allowed -- maybe one of the TCH folks can confirm this? If so, I wonder if there's an alternative way to run gpg? (Aside from this kind of application, it would be sort of cool...)

 

If this could be made to work, it seems to me like a pretty reasonable way to go about it -- the encrypted data should be secure, especially if it's encrypted on-the-fly and never actually stored, and if it's only de-crypted offline. But, it's kind of a roundabout solution and it really duplicates functionality that's probably done more soundly by one of the real commerce packages.

[TCH-Rob]

You may want to read this link in Security Discussions about a similar situation. I do not know if it will help or not in your decision to go this route, there are ways to do this but I cant say it is the safest route to take.

[snipe]

I could be wrong here (and google isn't helping much at the moment), but I am fairly certain that (at least in the US) there was a law passed - or was about to be passed - about sending credit card information through cleartext via email. It was something about IF you're going to send CC#s, you have to X out all but the last 4 digits. Again, I may be wrong, but before you go ahead with this kind of option, you should check and make sure that its still legal to even do that.

 

Otherwise you can use PHP to pipe your info directly through gpg or pgp (for email encyrption) - its not always as easy as it sounds, but it has been done before.

 

Real-time auth is still always the best way to go, that way you never actually store the CC# anywhere on your server - ever. Takes the liability off of your shoulders and often makes the buyers more comfortable too.