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.