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.