[ic] User options
Peter
peter at pajamian.dhs.org
Wed Apr 5 23:08:28 EDT 2006
On 04/05/2006 07:18 PM, Bill Carr wrote:
> Sorry I don't have an answer but I am glad you brought it up. I think
> Interchange does not save the CC number for security reasons.
Interchange *does* store the credit card number if you have set up PGP
encryption. IC will store the encrypted form of the credit card number
which can only be decrypted with the corresponding private key.
> We have
> not been storing credit card numbers but would like to be able to do
> the following:
>
> 1. Allow the user's payment details to remembered as you mention above.
> This is becoming a standard for major e-commerce site's (i.e.
> Amazon.com, Apple.com, etc.).
It's a simple matter to resend the stored PGP encrypted credit card data
when a new purchase is made.
> 2. Eliminate the need to send the PGP encrypted credit card number via
> e-mail. This is a confusing part of the process for the merchants we
> are doing sites for that I would like to eliminate. We are currently
> directing our customers to setup the encryption using Windows Privacy
> Tools. We would like to let the merchant see the CC number on the order
> detail screen and/or give them the ability to download a batch of
> orders for import into their POS/Accounting system. This transfer would
> happen via https.
This is a bad idea. While https does involve an encrypted session over
the internet (so that the number won't be transmitted in plain text)
this is not the easiest way to get a credit card number. In fact,
sniffing packets on a network to try to obtain a credit card number is
rarely used except in the most extreme cases. Much more common means
are to (1) install a key logger spyware onto the victim's computer or
(2) to hack into the server storing the credit card data and steal that
data in bulk. While you can't do much to protect the customer's
computer from spyware being installed (1) what you are proposing will
open your server(s) up to being able to obtain the data by grabbing it
from your server (as in 2).
With the current PGP encoding of the credit card data an attacker cannot
get the data off the server unless they also have the corresponding
private key (hint: *don't* store the private key on your Interchange
server, only store the public key there). They can hack into your
server and get everyone's credit card data, but not be able to read it.
In order to be able to present the credit card number via a browser
session your IC server will need to either store the credit card data
unencrypted or you will need to store the private key on the server so
that it can unencrypt it in real time.
The above is very important because under state laws in California and
many other states and under a proposed Fedral law, if your customers'
private data is compromised in an attack on your servers you are
required by law to notify everyone who might have had thier data
compromised. If the attacker only got encrypted data but cannot decrypt
it then there's nothing that was compromised. but if the attacker got
the data unencrypted or had access to the private key to decrypt the
data then you are in huge trouble because it is very bad for business to
tell your customers that some bad guy got thier credit card info from you.
> 3. Manage recurring billing (i.e. Wine Clubs)
That's a really tough one. The best way to go is to store the data
encrypted on one server, then allow that server access to another server
which will have the necessary private key to unencrypt the data and push
the transaction through the credit card processor (but does not store
the data post transaction), then you can keep the encrypted data
seperate from the key required to unencrypt it. There are probably
other ways to do this, that is just one way that comes to mind.
> For years I've been telling
> clients we never store credit card numbers.
That is incorrect, a better statement would be that all credit card data
is stored in an encrypted format so as to make it impossible for an
attacker to gain access to this data even if he manages to gain the
highest access privlidges on your system.
Peter
More information about the interchange-users
mailing list