RE: Encryption Advice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 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.

I assume you want to be able to unencrypt the credit card number for later
use, so a 1 way encryption method will not suffice.  In that case, I don't
know of a way to securly store this data in the environment you describe.
If someone gained access to you data, they would also likely have access to
your code and could therefore figure out how to unencrypt it.

That said, my first piece of advice: Never, ever store credit card numbers.
You are opening yourself up to a huge world of hurt by doing so.   Unless
you can come up with a reason (you probably can't) that you absolutely MUST
store credit card numbers on a shared server, don't do it.

> 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).

You are willing to risk bazillion dollar lawsuits on the "sufficiently
secure" file permissions of a "reasonably good" company?  I would suggest,
at minimum, getting a dedicated box with a well-known hosting company if you
are going to store credit card numbers.  At least then, you can enforce you
own security policies, and be reasonably sure you are the only one digging
around on the box.

> 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.

If you are going to rewrite the shopping cart application, why not look into
some ready-made ones.  http://www.oscommerce.com , a complete, free online
store, comes to mind immediately.  There are many others.  Search the
archives of this list if you're interested.  Why reinvent the wheel?  :)

> 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? 

On a shared server, you can't really protect it, but you can take some steps
to make it as difficult to get as possible.  Storing it outside of webroot
and giving it restrictive permissions would be good first steps.

You don't really go into much detail about your application.  But, if you
search the archives of this list for 'credit card', you will find some
really compelling reasons NOT to ever store credit card numbers.  If the
reason you are doing so is purely for customer convienience, you should
probably reevaluate that position.

JM

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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux