[ic] Re: User options

Peter peter at pajamian.dhs.org
Wed May 10 08:48:23 EDT 2006



On 05/10/2006 01:20 AM, Toni Mueller wrote:
> 
>>On Apr 5, 2006, at 11:08 PM, Peter wrote:
>>
>>>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.
> 
> 
> I think this is a bad idea. If the customer (the shop server) can
> decrypt the card details, the attacker can do it, too. So you gain
> nothing except for a second computer.

I don't believe I ever said that either the customer or the shop server 
could decrypt the card details.  The server that could decrypt the card 
details would only have the ability to forward them on to the payment 
processor.

That said, a lot of processors have the capability to process a new 
transaction for a customer given the transaction ID (and possibly some 
other bits of data exclusive of the sensitive cc#) of a previous 
transaction, thus allowing a site to perform recurring billing or 
correct an order, etc, without having to store the sensitive data or 
request it again from the customer.  If your processor has this 
capability then it would be much safer to use that instead of storing 
the card number yourself as you're offloading the risk (and thus the 
liability) onto the processor that way.

Peter


More information about the interchange-users mailing list