Damn, Bob copied me...or me him...i forget, but that was the essence of what
I was attempting to let the OP know...when dealing with security you can
never be paranoid enough
Bastien
From: "Neil Smith [MVP, Digital media]" <[EMAIL PROTECTED]>
To: php-db@lists.php.net
CC: [EMAIL PROTECTED]
Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely,two-way
encryption
Date: Fri, 06 Jan 2006 23:52:25 +0000
At 03:48 06/01/2006, you wrote:
Date: Thu, 5 Jan 2006 22:48:24 -0500 (EST)
From: Peter Beckman <[EMAIL PROTECTED]>
To: John Meyer <[EMAIL PROTECTED]>
cc: php-db@lists.php.net
Message-ID: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Re: [PHP-DB] Storing Credit Cards, Passwords, Securely, two-way
encryption
On Thu, 5 Jan 2006, John Meyer wrote:
Peter Beckman wrote:
So I'm thinking about how to save credit card numbers in the DB, for
re-charging cards for subscriptions, new orders, etc.
Yes yes, lawsuits, scary, etc.
I'm glad you're so blase about this and the threat of your business going
under due to exposure to extortion. When you've got the site running, let
me know the address, so I can advise my friends and colleagues to avoid it
at any cost.
I was looking for technical solutions,
i.e. maybe someone knows how USPS.com or Amazon.com or GoDaddy.com (do
they?) does it. Or if it is all security via obscurity.
Security by obscurity is a myth. There is no such security, nor will there
ever be (think of MS DRM cracks for example on a supposedly secure system).
Any system that interacts with the outside world *can* and eventually *will
be cracked.
> Best solution yet:
Nope, no solution at all. *DO NOT* store any credit card numbers on any
publically accessible system. Ever. Period.
Public key encryption, with additional either secret word padding or
using the users account password to pad/encrypt the card number
(preventing a brute force attack, even if access to the DB is given).
Prevents nothing. If somebody compromises your application server, then own
your "secret word padding" and can reverse the process to extract some or
all of the credit cards. Do not underestimate the resourcefulness of bored
people.
OK now to the candy : I've had this book a while, and it's one of the most
insightful and well researched (from experience) books on security I've
ever read. In fact - so good I'm going to go to the trouble to retype an
excerpt of a section called "One-Way Credit Card Data Path for Top
Security"
ISBN 0-13-0281870-5 [Prentice-Hall publishers]
Bob Toxen : Real World Linux Security [Now in 2nd edition]
====================
For many sites the most confidential information a customer can tell the
site is the customers credit card number and expiry date. Several e-com
sites (including some large ones) have had thousands of their customers cc
data stolen by crackers and have then had to respond to extortion threats.
Most e-com sites keep the database of customer information on the same
system as the web server and CGI programs. This is begging for trouble.
Simply putting the database on a separate system is not enough, because if
CGI programs can attach to the database across the e-com sites LAN,
security has not been improved.
(Bob Toxen) have come up with the concept of a one-way credit card data
path. By this I mean that the credit card data flows only one way, and that
way is into the credit card server but >data never flows out of the credit
card server< (my emphasis) except over a hardware path to the bank or
service that is processing charge requests.
The cc system would be a (linux) system dedicated to this one application.
It would have NO other applications on it, because each application would
be a potential security hole. It would be hardened for the highest
security.
It would have a separate private LAN to the web server, and the web server
would have a separate dedicated NIC to this private LAN to prevent sniffing
(snipped section about spot welded steel pipes encasing LAN cable !)
There would be >no< request implemented that would allow another system to
query for a complete CC number under any circumstance. Thus neither a
cracker hacking your web server, nor a disgruntled employee could get the
CC data from it. So long as there are no buffer overflow vulns, this should
be very secure, since there are no services to crack, no passwords to
crack, and spoofing would not work because the system doesn't trust >any<
other system at all.
When a customer establishes an account and specifies a CC, the CGI sends
the following message to the CC server :
ADD
user name
account number
cc type, number, expiry date, CCV#
When the customer wants to make a purchase, this is sent to the CC server
CHARGE
user name
account number
amount
The CC server then contacts the processing bank through the private network
to charge the amt, store the authorisastion number if successful and
returns either "Success" or an appropriate error message
Note that the comms link to the bank would be on a separate hardware to the
rest of the network, so if a cracker broke into the web or order DB server,
he could not >sniff< the network for these requests, because they wouldn't
be on that network.
If the user has multiple CCs on file, the following request might be used
LIST CARDS
user name
account number
The CC server would *only* reply with the last 3 digits, the rest replaced
with XXXX XXXX XXXX X319 for example
Obviously your web server should not retain any copies of the CC numbers it
handles. Use of encryption to and from the CC server is recommended, as is
IPTables locking down all ports except the CC and SSH request ports on the
CC server. The CC server code should be audited for buffer overflow
vulnerabilities, and run through Libsafe to detect buffer overflow
problems.
(followed by other stuff about social engineering and related admin issues)
====================
As Bob's book is so bloody good, here's the ASIN for it in case you want to
read all 650 pages of good advice ;-)
http://www.amazon.com/gp/product/0130464562/qid=1136589506/sr=8-1/ref=pd_bbs_1/104-3174210-9795945?n=507846
HTH
Cheers - Neil
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
