faqts : Computers : Programming : Languages : PHP : Common Problems : Ecommerce

+ Search
Add Entry AlertManage Folder Edit Entry Add page to http://del.icio.us/
Did You Find This Entry Useful?

20 of 26 people (77%) answered Yes
Recently 10 of 10 people (100%) answered Yes

Entry

How can I securely send credit card numbers from the server to the store owner?
How do I use email to send credit card numbers safely?

Jan 12th, 2000 23:32
Nathan Wallace, Dennis Nichols, Richard Lynch


You can send all orders from the server to the vendor via fax rather
than via secure email.  Point-to-point faxing seems to be accepted as
secure enough for the business world.

If you want to use email, there is a free (OpenSource) alternative to
PGP called gpg that's worth checking out:

    http://www.gnupg.org

There's even sample code in the mailing list archives using gpg
contribed by Richard Lynch and much improved by, err, Manuel Lemos
maybe?

At any rate, you want the popen() version, not the exec() version:
exec() will let the users on the SSL box read the credit card info using
'ps aux'...  On the other hand, if the people who can log into your SSL
box aren't to be trusted, you're in deep trouble anyway... Oh well, it's
a cheap extra security measure to use popen() instead of exec().

Quick run-down of how it works.

You use PGP (gpg) to generate a "key pair".  The "key pair" can be used
to encrypt/decrypt a message.  Guessing the other half of the pair from
just one half is theoretically impossible.  Decoding the message without
the other half of the pair is also theoretically impossible.

One "key" of the pair is "public".  The other is "private".  In this
case, you'll have the "public" key (and *ONLY* the "public" key) on the
SSL server, and use it to encrypt the data.  The "private" key will live
on your Client's computer only.

The encrypted email is sent to your Client. (Client in the human sense
of person who is supposed to get the credit card number).

This "private" key can also be password-protected so your Client's
employees can't just waltz in to his computer, read his email, and
decrypt it without knowing that password.

This will not scale well, of course, and it's really easier/cheaper to
juse use CyberCash or similar, but it's pretty hands-on, and can
integrate with the existing store-front fulfillment/ordering/processes.

Be aware that *most* fraud is still by normal humans in the storefront,
and your Client has to take security seriously to make this stay secure.