[thelist] Developing secure sites and waiving liability

John Olival johnolival at yahoo.co.uk
Mon Jul 15 11:09:04 CDT 2002


Why don't you store a unique reference number in the database instead of the
c/c number? E-mail the c/c number and unique reference number) to the
responsible person at your client. When they process the order/booking
(after they have downloaded the database), they can find the c/c number
applicable to that unique booking reference number. An alternative to
downloading the database is to have an interface (admin area) where your
client can view the unique bookings on line, instead of downloading the
database. Since the c/c details are not on the sever, the security risk is
reduced somewhat.

This should meet their needs? You will need to ensure the e-mails are secure
(PGP).

HTH

JohnO



----- Original Message -----
From: "Andy Warwick" <mailing.lists at creed.co.uk>
To: <thelist at lists.evolt.org>
Sent: Monday, July 15, 2002 4:01 PM
Subject: [thelist] Developing secure sites and waiving liability


> Hi
>
> I've been asked by a client to subcontract and develop an online booking
> application for a forthcoming conference, that involves taking credit
> card details and storing them in a database on the server.
>
> We've agreed that - as a bare minimum - the site/form should be done
> using SSL and a secure connection.
>
> The current plan is to store the inputted credit card details in
> plaintext in a mySQL database, so that they can be downloaded from a
> secure link as a CSV file, then loaded into the end client's database,
> from where the cards can be charged using their normal systems.
>
> I can't think of any way to encrypt the data to protect from casual
> eyes, that will still allow the end user to download the CSV file and
> use it. Technical competence at the end client level is negligible, so I
> can't encrypt the data held on the server and supply even the simplest
> 'un-encryption' routine on their own local systems; the data will have
> to be stored as it will be downloaded and viewed - in plaintext.
>
> I've already pointed out the inherent insecurities in such a system,
> especially as budget constraints mean that the server - and thus the
> database - are at their current ISP, on a standard account, and thus on
> a shared server with numerous other companies. The company I am
> subcontracting for consider this degree of risk 'acceptable'; the end
> client are so 'uneducated' re. web applications, that they wouldn't be
> interested in such technical details, and will blindly accept what my
> client tells them.
>
> I doubt if I am going to change their mind, and basically have two
> choices:
>
>     1.  Walk away.
>     2. Get them to sign some sort of form stating they understand what I
> have told them, and that they accept full responsibility if anything
> goes fubar, and that I won't be held liable.
>
> My instinct is to do number 1, but I need the work, and don't want to
> let my client down because *their* client isn't willing to spend 'big'
> money to get it right. In light of that, does anyone have suggestions,
> insight and - ideally - a boilerplate piece of 'legalese' I can use and
> can get them to sign to waive any liability.
>
> Obviously, any script I write will be as secure as possible within the
> confines of what I have to work with*, but it won'y be as secure as is
> *possible* with an unlimited budget; how has any one with experience in
> such matters coped with this sort of thing?
>
> TIA
>
> Andy W
>
> *password/login to enter site, validate input, check where variables are
> coming from, all pages done via SSL, etc., etc.
> --
> For unsubscribe and other options, including
> the Tip Harvester and archive of thelist go to:
> http://lists.evolt.org Workers of the Web, evolt !
>




More information about the thelist mailing list