Re: Encryption Advice
| From: | Richard Lynch | Date: | Fri, 19 May 2006 20:38:42 +0000 |
| Subject: | Re: Encryption Advice | ||
| References: | 1 2 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-236528@lists.php.net to get a copy of this message | ||
On Fri, May 19, 2006 8:54 am, Lawrence Kennon wrote:
> For an ecommerce site where sensitive data is stored
> either in files, or in a database, have you used some
> form of encryption to protect your customer's data?
>
> I have a client who currently uses a Perl scripted
> shopping cart that stores orders (including credit
> card numbers) in plain text files on a shared server.
> The security of these files depends purely on the
> user/file system security measures enforced by the
> hosting company (which I think is a reasonably good
> company, but still I don't see it as being
> sufficiently secure).
DO NOT STORE CREDIT CARD NUMBERS!!!
Period!!!
If your PHP script can access them, then they are too accessible to
the Bad Guys.
It's that simple.
> I am going to rewrite the shopping cart using PHP and
> was looking into ways to protect the data. Using GNU
> Privacy Guard (gpg) seemed like the ideal method
> because I could store the client's public key on the
> server to encrypt orders and the customer could then
> download the encrypted files and decrypt them on his
> PC with his private key (the client manually submits
> orders through his "store front" merchant account). I
> know this is a somewhat archaic procedure but it works
> sufficiently well for this client.
Just get a friggin' online merchant account, and process the orders in
realtime.
It's just not that expensive, and will save your client HUGE MONSTROUS
amounts of risk.
You can set up a recurring charge if you think you "need" the CC# for
that -- and then you get a Tx # from the merch and you do NOT need the
CC#.
> However the hosting company won't support gpg so that
> leaves me with PHP mcrypt functions which I think
> would work very well, except for on thing - how to
> protect the secret key which now has to be on the
> server?
It does?
Look, if you absolutely insist doing this the wrong way, AT LEAST make
the client upload the key for decrypting and then ERASE the key
immediately -- Or better, make him paste it into a big ol' textbox on
an https server, and never have it hit the hard drive at all.
> Any ideas/suggestions/experience along that line?
Years ago, I was gonna do what you propose, because my client was too
cheap to get a cert and pay the online merch fees.
Thank GOD people on this list stopped me.
Remember that game "hot potato" as a kid?
CC#s are hot potatos. Get it, process it, nuke it. Fast!
--
Like Music?
http://l-i-e.com/artists.htm