NYCPHP Meetup

NYPHP.org

[nycphp-talk] client doesn't want security: what to do?

tom at supertom.com tom at supertom.com
Wed Jan 7 16:54:03 EST 2004


David,

I know you are not going to want to here this answer, but I say do NOTHING,
and here's why:

You are a contractor (I'm assuming), you are paid to do what you are told.
What you are doing is not illegal, and you can provide documentation (I
assume you have sent her email about this) that you have informed her of the
risks.  I see no harm in asking her to sign something, but you are not
liable.

I am someone who is on the other end of this, meaning that I process orders
(over 100 a day) and frequently have to screen for fraudulent use of credit
cards that we take over our websites.  MANY times we have contacted local
authorities and Credit Card Companies with proof of fraudulent use (both in
the US and worldwide) of a particular card (used to purchase our products).
The sad reality is that no one actually cares.  Ultimately, it is the vendor
of the product who will have to eat the charge.  Why?  Because the Vendor
needs their merchant account to sell products, the customer will just get
another credit card if they feel they are treated unfairly.  The Credit Card
companies just pressures the vendor into eating the charge, or else they get
their rates raises, which can hurt business badly.  Because of this, we have
focused our efforts in developing checks to help insure that we don't charge
(and ship products for) a misused card.

So, in the eyes of the CC companies, they don't care if you are keeping
cards safe of people who have purchased your products.  What they really
care about is false charges on one of their cards.  The whole idea is turned
on its head.

I commend you for wanting to add security, and agree that it should be
there.  Personally, I think she doesn't want to upset her applecart by
learning something new, and probably doesn't want to pay you for the work
required to do this.  How we get around this is by offering these methods as
the only solution in the beginning, so the client start off immediately with
these features, and they accept "that's just how it is".

Good Luck,

Tom





***************************************************
What's Tom listening to right now?  Find out here:
http://www.supertom.com/current_track.php




-----Original Message-----
From: talk-bounces at lists.nyphp.org
[mailto:talk-bounces at lists.nyphp.org]On Behalf Of David Mintz
Sent: Wednesday, January 07, 2004 4:27 PM
To: NYPHP Talk
Subject: [nycphp-talk] client doesn't want security: what to do?



A developer -- let's called him yours truly -- has had a nagging problem
for a while. Client -- let's call her C -- has websites, hosted on a
shared server, that collect sensitive info. Said info is written to a
database for temporary storage -- up to a couple weeks, then wiped out via
a cron job whether C has gotten around to getting it or not. C logs onto
to an SSL-encrypted password-protected page to fetch info. Yours truly has
made every effort to make this system as secure as possible under the
circumstances -- e.g., running PHP in cgi mode and making all the
permissions as restrictive as possible, using SSL, etc.

However, yours truly thinks it would be better to use GPG or PGP for
encryption, but C cannot be persuaded to acquire, install and start using
PGP/GPG and thus keeps ~not~ providing yours truly with her public key
despite numerous requests.

Alternatively, yours truly thinks it might be more secure than the status
quo to go straight to an online payment gateway via SSL and process the
you-know-what in real time. C thinks this is unnecessary.

Your truly thinks it's time to prepare a written form for C to sign,
wherein she acknowledges having been advised of the risks and explicitly
states she wants to do it her way anyway.

What do you think?

Many TIA,



---
David Mintz
http://davidmintz.org/

        "Anybody else got a problem with Webistics?" -- Sopranos 24:17
_______________________________________________
talk mailing list
talk at lists.nyphp.org
http://lists.nyphp.org/mailman/listinfo/talk




More information about the talk mailing list