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.
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.
"Do not underestimate the resourcefulness of bored people."
These people aren't necessarily bored. Just more intelligent than
yourself and on a higher income :-)
Have you ever done any cryptanalysis? Have you ever succeeded if so?
Do you know some people are employed to actually experiment and test on
known modern cyptographic methods in order to ascertain their
effectiveness?
Rather than to live in your little world where everything is cherry and
pretty, most people of our profession are aware to the reality that we
can't all hide under 2048bit/2KB key length encryption utilities..
I am somewhat disappointed at the approach you are taking towards people
who are in the business and field of security and discovering and in
turn rectifying or improving existing security systems.
I guess its true then, ignorance IS bliss... Pretend the system IS safe,
and it must be! Don't ever let any of those "bored" people test the
limits of the system. Hell why benchmark cars, computers, military
weapons, athletes or anything for that matter!! As long as they "think"
they're the best, they MUST be!
Wake up mate!
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
