> -----Original Message-----
> From: Peter Beckman [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 7 January 2006 4:05 PM
> To: Dan Baker
> Cc: php-db@lists.php.net
> Subject: Re: [PHP-DB] Re: Storing Credit Cards, Passwords, Securely,
> two-wayencryption
> On Fri, 6 Jan 2006, Dan Baker wrote:
> > "Peter Beckman" <[EMAIL PROTECTED]> wrote in message
> >> 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"
>   believe they have smart people that have more resources available to
>   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
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
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

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!

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to