Wow....I was hoping someone would respond with a little balance to that reactionary doomsday speech. Don't get me wrong...those are some very valid points that need to be considered, but my gosh... The key-pair idea is very good. I've done systems in the past for clients that work in a similar fashion. There are multiple layers of security with two main aspects: 1. The technical implemenation and complexity of the system 2. The responsibility/priveledges granted to users/admins You can come up with the most complex, technical "secret key" solution around (aspect #1)....but if you entrust that secret key to the wrong person (aspect #2), it's all for nothing. In the end...it's about common sense. It's FAR less dangerous to implement what you are suggesting than it is to simply pay for your dinner with a credit card. One thing I agree with Richard wholeheartedly on is his "Hi, I'm about to perform brain surgery. Which scalpel should I use?" anology. If the technicaly aspects of implementing a system like this escape you...then please learn how to do it in theory first. Don't "learn on the job" with something as precious as your credit rating. Hope this helps Brandon > -----Original Message----- > From: Richard Lynch [mailto:ceo@xxxxxxxxx] > Sent: Wednesday, February 02, 2005 1:34 PM > To: Angelo Zanetti > Cc: php-general@xxxxxxxxxxxxx > Subject: Re: Credit card storing, for processing > > Angelo Zanetti wrote: > > thanks for the info. With regard to the setup it will be something > > more or less like this: > > DON'T DO IT!!! > > > I want to generate my own keypair. The private key I keep secure, > > offline, on the machine that does the admin (charging, > refunds etc). > > The public > > > > key is used on the server to encrypt card details the minute they > > arrive on the server (even using SSL, the data will arrive > unencrypted > > because the web server decrypts it). > > > > Encrypted card details are written to file, and moved off > the server > > overnight by a cron job. > > > > On the admin machine, offline, the details get decrypted > when needed > > to perform transactions, using the private key. > > Who has access to the private key? > > Under what circumstances? > > How are you going to STOP a determined individual from > compromising the access to the private key? > > Do you have $50,000 in escrow for *WHEN* (not if, *WHEN*) > that key is compromised? > > Are you prepared to put another $100,000 in escrow *after* > that time for the next time it *WILL* happen? > > Are you prepared to contact EVERY credit card customer and > tell them their credit card security was compromised? > > > The admin box is on ADSL, but behind a firewall with no services or > > ports open to the internet. I.e it can initiate a > connection to the > > server on the internet, but not the other way around. > > > > Does this setup sound secure enough and a solution that can work? > > NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! > > Who has physical access to the admin box? > > How is it locked down? > > When will the audits be conducted? > > By whom? > > You're missing about a ZILLION things here... > > > What kind of encryption should I be using? > > If you have to ask, you shouldn't be doing this: > > "Hi, I'm about to perform brain surgery. Which scalpel should I use?" > > You are NOT ready to implement the system you have envisioned. > > Let the credit card companies take the risk. They've got the > resources for it. That's why things are the way they are. > > I *almost* did the same kind of thing you are about to do. > Thank [deity] I came to my senses first. > > I cannot stress this enough. > > DON'T DO IT! > > Sorry, dude. It's just *NOT* a Good Idea. Deal with it. :-) > > -- > Like Music? > http://l-i-e.com/artists.htm > > -- > PHP General Mailing List (http://www.php.net/) To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
