[Pdx-pm] saving state with CGI.pm

[Kyle Hayes]

On Wednesday 05 November 2003 11:08, Austin Schutz wrote:
> On Thu, Nov 06, 2003 at 10:21:47AM -0800, Ovid wrote:
> > --- Austin Schutz <tex at off.org> wrote:
> > > 	One way to do it is to use cookies. Benefits are that you don't
> > [snip, horror stories]
> > You can read about those horror stories of storing user data in the
> > cookies.
>
> 	Three points of rebuttal... err.. I guess four:
>
> 	1. If a credit card number has to be stored, I'd much rather have it
> stored on my computer than on some poorly maintained webserver run
> by joe shmoe on the other side of the 'Net.

??? but browsers will give it up to any server persuasive enough.  Cookie 
attacks are legion.  Tried cranking down control of your cookies real tight 
and then using Hotmail?

HTTP cookies are like VD infections: they spread easily and no one wants to 
talk about it.

Really, really important information I keep offline if at all possible.

> 	2. You shouldn't be storing credit card information anyway.

Tricky to do if you need recurring billing.  I agree that the best approach is 
to do everything possible to avoid storing a credit card in any form that 
could be turned back into a usable number.

It is worth doing all kinds of gymnastics to avoid storing CC numbers in any 
usable form.

> 	3. Encryption works swell. Just because the data is stored on the
> user's computer doesn't mean it has to be available in plaintext.

This is only true when the decryption method is as safe as the credit card 
data itself.  I.e. you've got all your credit card numbers carefully 
encrypted, but the Perl CGI that has the decryption key and salt is 
downloadable via misconfiguration or a web server bug....  Ouch.  I've seen 
it happen.

I've seen people make MySQL loadable user modules (compiled C++ code) to do 
the decryption.  Great, tough to make the web server serve that module up as 
a binary.  However, a little trickery, a couple of SQL injection attacks, and 
again, I've got your decryption key, or I can get your server to do the 
decryption for me.  Cool.

I prefer doing one-way crypto hashes on CC numbers.  MD5 is a bit long in the 
tooth, but SHA1 and some of the newer, stronger crypto hashes do a fine job.
You can't get the number back, but you can tell if you get the same CC twice 
(which is useful in stopping potential fraud).    Sure, someone can crack 
your web site and stripmine the DB. Big deal. You haven't given away any CC 
numbers.  

It's far too easy to win the Visa lawsuit sweepstakes.

The Secret Service will not help you.  Visa will not help you.  The first is 
too busy with too few people to do much.  The second makes money on every 
transaction, coming or going.  You are not worthy to talk to American 
Express.

> 	In addition to the point that if you can't trust the other users
> on an insecure operating system you shouldn't be using it anyway. In the
> "young lady" story her parents could just as well have installed a
> keystroke logger, etc. etc. etc.

As noted in other venues (and on this list): The end points are not secure, 
but the transport is great.  A bit of a conundrum for those of us that 
sometimes need to make sure that secret data stays secret.

Best,
Kyle