[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.


More information about the interchange-users mailing list