Re: credit card conventional wisdom

[anonymous-remailer@shell.portal.com]

Alice here ...

On Wed, 15 Nov 1995, Howard Melman wrote:

> Vladimir Z. Nuri wrote: 
> > attempts to get secure credit card number transfer on the internet are
> > not an end in themselves. they are the first steps toward an entirely
> > new transaction system. those who see a single step and criticize it 
> > as feeble in the context of past systems are missing the point and
> > apparently can't think past the present nanosecond of their lives. 

My grandfather used to say, that the first horse to break from the gate,
isn't necessarily the first to cross the finish line. 

Often, he'll be pulling up the rear.

> You'll have a hard convincing folks that they need something
> better than what works perfectly well today.

In my humble opinion, the present system can't really be characterized as
"working perfectly well".  Far from it.  

While not as familiar with the US system as the Canadian, I can give as a
simple example, the bank clearing system for paper checks.  In Canada, we
can clear a check from one side of the country to the other overnight.  We
have 24 hour clearing.  While this is far from "perfect", our existing
paper systems allow for a degree of efficiency which I don't believe is
engineered into the US clearing system. 

Perhaps someone can correct me, if I have erred but I think it takes far
longer than 24 hours to clear a check drawn on any US bank, and deposited
to any other bank's credit in the United States.  It may work
"functionally" ... but certainly far from "perfectly" nor "efficiently". 

> Here's another point that I didn't see in your list.  Today it might be
> just as safe to send your CC# over the internet as giving it to a clerk,
> etc.  This is mostly because the number of CC#'s sent over the net vs 
> the whole traffic is small.  It is therefore not very cost effective to
> try to steal credit card numbers over the net vs other means (searching
> through dumpsters, taping a phone line near LL Bean, etc.). 

A very good point.  But then, dumpster-diving attacks could be moderated
by simply implementing carbonless forms.  No carbon, reduces a lot of the
risks.  It's basic risk management. 

All of this becomes a part of the cost/benefit analysis, and is part of
the function of security policy.  It's very much like all the talk on
another thread on this list about Java security. 

There is no point in even discussing Java security in Netscape, when
Netscape PRESENTLY has existing security holes written into the very
fabric of the existing installed codebase.  Holes which Netscape and AT&T
refuse to address, correct or even comment on. 

Sun's security approach misses the point.  Putting dead-bolts on houses
while leaving all of the windows open, just doesn't address the problem. 
It really misses the mark. 

> If CC# purchases became common over the net, it would become much more
> valuable to try to steal them from the net and more people would.  It
> would then become much less secure, not for any technical reason but
> because there will be more crooks exploiting the existing flaws. 

This is also unfortunately true.  Information on how to "break" a system
does propagate.  As more people know how to exploit a system, or as more
people learn how to utilize the "letter of the rules" (the "code") rather
than the "spirit" (the "intent") the degree of exploitation grows. 

Ask any executive in the Gaming Industry about this.

Black-Jack card-counting went through an evolution in exactly this
fashion.  Many casinos lost a veritable "fortune" to good card counters. 
They lost to organized "teams" of card counters.  Counters who literally
broke the bank. 

Systems always have exploitable features.  And new systems will always
present new opportunities for exploitation. A completely new set of risks
which are additive to those already in place, even those which may not 
yet be in a state of active exploitation.

A pertinent network example: credit card numbers.

Credit card numbers are not just a set of random digits.  Only particular
patterns of numbers can be valid.  This existing "security provision" --
check digits -- actually ends up opening a security hole when we look at
transmitting credit card numbers via the Internet. 

The security feature on one side of the ledger makes it far easier to
differentiate between what is a random set of numbers, and what is in fact
a valid CC number.  Simple pattern analysis allows to search for valid
numbers.  

It makes the potential "crooks" job much easier and its already engineered 
into the system.  

The "credit card number" risk though is accidental, while the Netscape
Navigator risk isn't accidental at all, it's willful. 



Alice de 'nonymous ...

                                  ...just another one of those...
                                                   ...hunters...

P.S.  This post is in the public domain.
                  C.  S.  U.  M.  O.  C.  L.  U.  N.  E.