> -----Original Message----- > From: Peter Beckman [mailto:beckman@xxxxxxxxxxxxx] > Sent: Saturday, 7 January 2006 4:05 PM > To: Dan Baker > Cc: php-db@xxxxxxxxxxxxx > Subject: Re: Re: Storing Credit Cards, Passwords, Securely, > two-wayencryption > > On Fri, 6 Jan 2006, Dan Baker wrote: > > > "Peter Beckman" <beckman@xxxxxxxxxxxxx> wrote in message > > news:20060105202254.X8551@xxxxxxxxxxxxxxxxxxxx > >> So I'm thinking about how to save credit card numbers in the DB, for > >> re-charging cards for subscriptions, new orders, etc. > >> > >> I'm also thinking about how to save passwords in the DB, not plaintext, > >> but not one-way encrypted either. > >> > >> Any suggestions? How would I secure the database? I'm thinking some > >> abstract process in code, or something -- security through obscurity. > > > > [Summary: Call Verisign, pay THEM to store credit cards for you] > > What, exactly, does VeriSign do, that makes you so sure that they have > secured the credit card information any better than I could, using a > well-thought-out system? Do you even know? You just hear "VeriSign" and > believe they have smart people that have more resources available to them > to do a better job securing the data? They don't. What they do have is more financial muscle to deal with a stuff up of the nature that CardSystems perpetrated. Similarly because of the scale they can afford to invest more $ (same proportion as you but much more in absolute amounts) in R+D to protect against the downside. > Maybe this makes sense if you are doing a few hundred or a few thousand > dollars of business a month, but if you are planning on doing $5,000 to > $10,000 a day, it is a lot of added expense to have someone else do it, > when I could have it done internally. It is the how. Sure, why give away margin if you can solve the issue locally. > Please, no more replies saying don't do it. Just do it with your eyes wide open. BTW you should get your legal eagles to review the fine print of your gateway agreements to assess whether you are "allowed" to store the information. Even if they explicitly prohibit the storage of course you can go ahead and cache the numbers. But be warned that should it all go pear shaped they will cut you loose to the hordes of lawyers that will surely descend to feed on the carcass of your company. On the subject of how to do it? The host of the CC numbers should at least (i.e. not an exhaustive list) ... a) Not be internet or internally facing. i.e.. in a physical DMZ with an mains power connected to the keyboard :-) to stop casual users snooping around, b) perform no other tasks at all! No web surfing, no email, no nothing, only backup in encrypted form. c) seriously encrypt everything - no mickey mouse xor stuff, d) must be firewalled from the web server with a keyhole open for communication, e) must perform all communications with the bank/gateway provider and only return success/fail to the webserver - never ever return CC numbers! To bad if you want to replay the number to the user. f) log everything ideally on a one way basis to another server with worm media and scan the logs frequently for weird stuff. Make sure it screams like crazy if the log stream appears to be interfered with. Hopefully with these sorts of controls the damage will be less than your balance sheet can withstand. BTW you prolly won't get any insurance of this risk unless you are prepared to pay a big premium - which defeats the purpose! Others no doubt will be able to add more control layers - these are just what first comes to mind in a few minutes. Bon voyage! Frank. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
