[Zope] Secure storage of credit card info

[Cary O'Brien]

> OK, any of you out there who have thought about ecommerce, cryptography,
> and zope, I've got a design question for you.  Actually, this question
> is independent of zope, but I need to solve it in a zope context.
> 
> You have a ZCommerce site.  You accept credit cards, and securely
> communicate with a CC processor to verify the transacton.  Now,
> you want to save the CC# and other info in case something needs
> to be done with it later, and probably store the CC# so this
> customer doesn't have to type it in again later.  Regardless
> of whether you are storing this info in a relational database
> or in the ZODB, how do you secure that information?  Ideally
> I'd like it to be encrypted on disk.  Now, storing it in a database
> probably makes it pretty hard to grep out even if a hacker
> manages to snarf the database file, but I'd like to encrypt it.
> But if I encrypt it, I have to have a decryption key somewhere.
> Where do I store the decryption key so that the cracker who
> snarfs the database file can't get it (just in memory somewhere?),
> and yet have the system be able to boot itself, including having
> the key, without human intervention?  It seems to me like
> this is a Hard Problem, but I'm not up on the current
> cyrptography practice.  So if there is a well known general
> solution, I'd love to hear about it.  Otherwise, does anyone
> know what current Best Practice is?
> 

Good question.  I was just talking to someone about this a few
days back.  What they did was to

	a) create a public/private keypair.  Don't
	   leave the private key ANYWHERE except on
	   the CC verification machine (described below)

	b) encrypt the data using the public key

	c) store the encrypted data

	d) ship the encrypted cc information through
	   an internal firewall[1] with one hole to a 
	   CC verification back end.  This back end
	   is protected as much as possible, accessible
	   by as few people as possible.  It uses the
	   private key to decrypt and verify.  

You are still vulnerable if someone can get in and snarf
the CC information during b), but at least you don't have
thousands of CC numbers hanging around on your frontend
or database machines.  The idea is that the CC verification
machine is much less likely to be compromised.

Best practice?  I don't know.  But it sounded like a good
idea to me.

Hope I got this right. (Hi Ramon!)

-- cary

[1] Which also needs to have limited access.