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 _______________________________________________ interchange-users mailing list suppressed http://www.icdevgroup.org/mailman/listinfo/interchange-users
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.