[Pdx-pm] saving state with CGI.pm
kyle at silverbeach.net
Thu Nov 6 22:55:38 CST 2003
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:
> > [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
> 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
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
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
> 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.
More information about the Pdx-pm-list