FYI -- Bank of America and Netscape
Marc Andreessen
Cheers,
Marc
BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
NETSCAPE COMMUNICATIONS SOFTWARE
MOUNTAIN VIEW, Calif., Dec. 5 /PRNewswire/ - Netscape
Communications Corporation, a premier provider of open software for
the Internet, and Bank of America, the largest merchant bank in the
United States, today announced that Bank of America will provide
businesses with a secure means for electronic commerce on the
Internet using Netscape Communications' secure client/server
software. Bank of America, which will begin offering the service
next month, will be one of the first banks providing real-time
online card authorizations.
Bank of America's payment service will allow businesses wanting
to conduct commerce over the Internet to accept consumers' Visa(R),
MasterCard(R), Discover Card(R), Diners Club(R), Carte Blanche(R),
JCB Card(R) or American Express Card(R) online. Netscape
Communications' software provides encryption so that a consumer's
card number can be sent securely to Bank of America for real time
processing. The service is free to consumers buying goods or
services on the net.
"This partnership with Bank of America represents a significant
step in providing consumers and businesses with a secure means for
payment and credit card authorization online," said Jim Clark,
chairman and CEO of Netscape Communications. "Bank of America
reaches a significant percentage of merchants who today use
traditional bankcard payment processing services. With this
announcement, Bank of America takes a leadership role in confirming
for companies and consumers that the Internet is a safe and
efficient channel for conducting business."
"We researched payment schemes available for the Internet and
found that Netscape Communications is providing the fastest, most
secure, and most open environment for online payment processing,"
said Sharif Bayyari, senior vice president at Bank of America.
"Other payment options on the net come with high transaction risks,
bypass bank payment systems and open the way to fraud and consumer
liability. This approach eliminates those concerns and allows
companies and consumers to feel comfortable and confident conducting
business on the Internet."
Bank of America's service will be based on Netscape
Communications' Netsite(TM) Commerce Server software, with
additional transaction processing capabilities to handle payment
processing. Fully compatible with existing HTTP-based clients and
servers, the Netsite Commerce Server incorporates Netscape
Communications' Secure Sockets Layer based on RSA Data Security
technology. The technology provides encryption, which creates a
secure channel to prevent anyone on the network from tapping into
the transaction; and authentication, which verifies the legitimacy
of the server. The Commerce Server is designed for online
transactions and electronic data exchange, enabling users to feel
secure sending sensitive documents over networks.
To take advantage of the new online capabilities, Bank of
America's business customers create their own Internet presence or
virtual storefront using the Netsite Commerce Server, and then
enroll in the service through Bank of America. Consumers using
Netscape Communications' Netscape Navigator(TM) 1.0 can then access
and establish a secure link with the server, enabling credit card
information to be sent securely over the net. The card information
is then processed by Bank of America in real time.
Netscape Communications' Netsite Commerce Server and Netscape
Navigator 1.0 will be available this month.
BankAmerica Corporation (NYSE: BAC) is the second largest bank
holding company in the United States based on assets of $197.2
billion, operating more than 1,900 branches and 5,000 ATMs in 10
western states. It provides credit and banking services to
individual consumers, small to mid-sized businesses and large
corporations, nationally and internationally.
Netscape Communications Corporation is a premier provider of
open software to enable people and companies to exchange information
and conduct commerce over the Internet and other global networks.
The company was founded in April 1994 by Dr. James H. Clark, founder
of Silicon Graphics, Inc., a Fortune 500 computer systems company,
and Marc Andreessen, creator of the NCSA Mosaic research prototype
for the Internet. Privately held, Netscape Communications
Corporation is based in Mountain View, California.
NOTE: Additional information on Netscape Communications
Corporation is available on the Internet at http://home.mcom.com, by
sending email to infomcom.com or by calling 1-800-NETSITE. Netscape
Communications, Netsite, Netscape Navigator and Netscape are
trademarks of Netscape Communications Corporation. All other
product names are trademarks of their respective companies.
--
Marc Andreessen
Netscape Communications Corp.
Mountain View, CA
ma...@mcom.com
Rob Francis
>BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
>NETSCAPE COMMUNICATIONS SOFTWARE
Interesting, I'm curious (if it's public information), will Bank
of America only be offering the ability to send a card number
over the wire encrypted, not really doing authentication of the
client?
As in, if I find someone's credit card, I could use NetScape to
send te number over the wire encrypted and now there's not even a
signature to verify it's really the card holder. Unless Bank of
America is going to be registering public keys, but the release read
like it's just encrypted using the session key and nothing more.
Just curious.
-rob
---
Rob Francis
Paradigm Systems http://www.sf.psca.com
Rob_F...@sf.psca.com
Mike Kenney
Rob Francis <rfra...@sf.psca.com> wrote:
>
>>BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
>>NETSCAPE COMMUNICATIONS SOFTWARE
>
>Interesting, I'm curious (if it's public information), will Bank
>of America only be offering the ability to send a card number
>over the wire encrypted, not really doing authentication of the
>client?
>
>As in, if I find someone's credit card, I could use NetScape to
>send te number over the wire encrypted and now there's not even a
>signature to verify it's really the card holder. Unless Bank of
>America is going to be registering public keys, but the release read
>like it's just encrypted using the session key and nothing more.
>
>Just curious.
I'm curious about this as well, Netscape's secure protocol seems to
handle encryption and client authentication but not *user* authentication.
I know there is some commercial service out there that is authenticating
WWW transactions using PGP ... that seems like the way to go.
To anyone at Netscape: Is there some reason to not use PGP sigs for
authentication?
--
Mike Kenney
mi...@apl.washington.edu
Mubashir Cheema
>>BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
>>NETSCAPE COMMUNICATIONS SOFTWARE
>Interesting, I'm curious (if it's public information), will Bank
>of America only be offering the ability to send a card number
>over the wire encrypted, not really doing authentication of the
>client?
>As in, if I find someone's credit card, I could use NetScape to
>send te number over the wire encrypted and now there's not even a
>signature to verify it's really the card holder. Unless Bank of
>America is going to be registering public keys, but the release read
>like it's just encrypted using the session key and nothing more.
>Just curious.
You would have to setup a merchant account with the Bank before you
can do anything. You will also have to sign a merchant agreement with
the bank that will make sure that you make proper use of services
provided to you by the bank.
Mubashir Cheema
Sparco Communications Corporation WWW : http://www.sparco.com/
Sales : (800) 840-8400 Email : spa...@sparco.com
Customer Service : (601) 323-5360 Ftp : ftp.sparco.com
Fax : (601) 324-6433 Automated Email: mails...@sparco.com
Derek Harding
>
> >BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
> >NETSCAPE COMMUNICATIONS SOFTWARE
>
>
> send te number over the wire encrypted and now there's not even a
> signature to verify it's really the card holder. Unless Bank of
> America is going to be registering public keys, but the release read
> like it's just encrypted using the session key and nothing more.
>
signature, the main check is that the credit card has not been reported lost
or stolen.
Derek
--
Derek Harding de...@pipex.net
Product and Software Developer
PIPEX (Public IP Exchange)
#include <std_disclaimer.h>
Joe Buck
Followups are directed to comp.infosystems.www.misc.
Rob Francis <rfra...@sf.psca.com> wrote:
>>As in, if I find someone's credit card, I could use NetScape to
>>send te number over the wire encrypted and now there's not even a
>>signature to verify it's really the card holder.
Ever charged anything over the phone? Signatures aren't needed to
charge something with a credit card, only the number and the expiration
date. Netscape isn't opening any new holes.
mi...@wavelet.apl.washington.edu (Mike Kenney) writes:
>I'm curious about this as well, Netscape's secure protocol seems to
>handle encryption and client authentication but not *user* authentication.
>I know there is some commercial service out there that is authenticating
>WWW transactions using PGP ... that seems like the way to go.
Netscape uses the RSA algorithm, just like PGP. I suspect, though, that
it just encrypts your card # with the merchant's public key.
Apparently, though, Netscape is using rather short keys -- NSA will let
you export cryptography provided that it's weak enough for them to crack.
>To anyone at Netscape: Is there some reason to not use PGP sigs for
>authentication?
The merchant doesn't need this authentication: all they need is the
number. If the charge is fraudulent, it can be challenged when the
customer gets the bill. Given that this is the way that the credit
card industry already works, adding a digital signature is overkill.
There's no signature when you charge by phone.
--
-- Joe Buck <jb...@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729
Lloyd Zusman
> For the last few weeks I've been trying to raise a point here. How
> do existing web servers interact with the merchant banks. Let's say
> xyz.com is running a Netsite server and receive a VISA charge from a
> Netscape client. Your server decrypts the info giving you the VISA
> cardholder number. Great, but how do you turn around and forward
> that to BofA (or FDR) or whoever to get the authorization. Does
> your Netsite server have to connect (with SSL) to BofA (or any
> merchant bank) netsite server? And then when the merchant bank gets
> the authorization code back from the VISA BASE (BASE is the world
> wide VISA transaction and authorization network) system???????
> The way I am reading this lately that ONLY merchant bank type of
> operations will be able to handle real-time authorizations. So is
> this the way mcom is going???????????
This is a good point, and I would like to know, as well.
Also, here's another, related issue:
The encryption of the credit card number has to take place on the
client side (in Mosaic, Lynx, Netscape, etc.), or else plaintext
credit card numbers will be sent over the net. How is this handled?
Would every subscriber to this credit card service have to be using
only BofA-compliant Web browsers? If so, this would greatly curtail a
business's ability to make money on the web, because all of its
customers and clients would have to be using a compliant browser or
else no secure credit card purchases could be made.
Am I missing something?
--
Lloyd Zusman 01234567 <-- The world famous Indent-o-Meter.
l...@panix.com ^ I indent thee.
To get my PGP public key automatically mailed to you, please
send me email with the following string as the subject or on a
line by itself in the message (leave off the quotation marks):
"mail-request public-key"
Jim Lustgarten
existing web servers interact with the merchant banks. Let's say xyz.com is
running a Netsite server and receive a VISA charge from a Netscape client.
Your server decrypts the info giving you the VISA cardholder number. Great,
but how do you turn around and forward that to BofA (or FDR) or whoever to get
the authorization. Does your Netsite server have to connect (with SSL) to
BofA (or any merchant bank) netsite server? And then when the merchant bank
gets the authorization code back from the VISA BASE (BASE is the world wide
VISA transaction and authorization network) system???????
The way I am reading this lately that ONLY merchant bank type of operations
will be able to handle real-time authorizations. So is this the way mcom is
going???????????
In article <marca-05129...@boulanger.mcom.com> ma...@mcom.com (Marc
Andreessen) writes:>From: ma...@mcom.com (Marc Andreessen)
>Subject: FYI -- Bank of America and Netscape
>Date: Mon, 05 Dec 1994 14:59:05 -0800
David Messner
Lloyd Zusman <l...@panix.com> wrote:
>Also, here's another, related issue:
>
>The encryption of the credit card number has to take place on the
>client side (in Mosaic, Lynx, Netscape, etc.), or else plaintext
>credit card numbers will be sent over the net. How is this handled?
>Would every subscriber to this credit card service have to be using
>only BofA-compliant Web browsers? If so, this would greatly curtail a
>business's ability to make money on the web, because all of its
>customers and clients would have to be using a compliant browser or
>else no secure credit card purchases could be made.
>
>Am I missing something?
Granted, the client has to handle the encryption of the card number to
send to the httpd server (Netsite being the only one right now). But
this step has nothing to do with BofA. Once it gets to the server,
the server (or a CGI script?) could then use whatever encryption
scheme to send a validation request to BofA, and receive the
reply. The client never has to know about BofA, or what encryption
scheme is being used to communicate with BofA, only the httpd server
side needs to know that.
And yes, certainly we do need a standard for the encryption from
client to server. I applaud Netscape for proposing such a standard
and making it public.
Dave Messner
dmes...@vt.edu
Lloyd Zusman
> In article <LJZ.94De...@panix.panix.com>,
> Lloyd Zusman <l...@panix.com> wrote:
>> Also, here's another, related issue:
>>
>> The encryption of the credit card number has to take place on the
>> client side (in Mosaic, Lynx, Netscape, etc.), or else plaintext
>> credit card numbers will be sent over the net. How is this handled?
>> [ ... ]
> Granted, the client has to handle the encryption of the card number to
> send to the httpd server (Netsite being the only one right now). But
> this step has nothing to do with BofA. Once it gets to the server,
> the server (or a CGI script?) could then use whatever encryption
> scheme to send a validation request to BofA, and receive the
> reply. The client never has to know about BofA, or what encryption
> scheme is being used to communicate with BofA, only the httpd server
> side needs to know that.
Right ... but this still involves a problem that may persist for quite
a while:
Let's say I am a small business that wants to use the Web to
facilitate catalog orders. My Web server is connected to,
say. BofA's validation system, and so I am guaranteed that CC
numbers going between my system and BofA are safely encrypted.
However, I advertise my home page, and people from all over the world
connect to my home page. Presumably, these people will be using all
sorts of different Web browsers: Lynx, Netscape, Mosaic, Web Explorer,
etc. There will be differing releases of these browsers, too.
So if some random person wants to place an order through my catalog
and they are prompted for a credit card number, there is no guarantee
that my software will be able to read the credit card number that is
being sent from their client site to my server ... and if they are
using the "wrong" version of client software, then they may have to
send their CC number as plaintext. Many people may not want to do
this, and this could hurt my business.
> And yes, certainly we do need a standard for the encryption from
> client to server. I applaud Netscape for proposing such a standard
> and making it public.
Well, after a while some standards will be agreed upon, but it is
likely to be months or maybe a year or more before all the commonly
used Web browsers will adhere to whatever client-to-server encryption
standard is finally decided upon.
In the mean time, is there something less "elegant" that can easily be
put into place as an iterim solution that doesn't require people to
change their existing Web browsers, which would allow CC validation to
take place without any plaintext CC numbers being sent over the net
from the clients to the server?
I can't think of anything, myself. Any ideas?
Rob Francis
> Sounds the same as what happens with mail ordering via credit card to me. No
> signature, the main check is that the credit card has not been reported lost
> or stolen.
Yes, exactly. I wasn't trying to rip on Netscape or anyone, merely
raising the question. Personally, I don't use credit cards over
the phone, but I don't deny this is a common occurance. My
question was just how/if Bank of America was planning on doing
authentication. As has been pointed out, they don't really have
to, it'd be just like mail order today.
However, the chance to use registered public keys is there. I
thought perhaps Bank of America would make use of it, along
with NetScape. I haven't seen much from the docs at mcom.com
about how a person would go about using their own private key,
rather than the session key that is agreed upon by the client
and server.
I'm not bashing anyone, just airing some thoughts on the matter.
Jim Lustgarten
>From: l...@panix.com (Lloyd Zusman)
>Subject: Re: FYI -- Bank of America and Netscape
>Date: 6 Dec 1994 19:10:22 -0500
Another guess on connecting the Netsite secure server back to the VISA
authorization system could be two ways.
1. Let the Netsite server emulate the existing POS system. The Visa
networks already have this support in place, usually over a phone line.
Interface Netsite to the phone using POS info and systems which is
pretty standard in the Visa industry.
2. The other would be to have the server recrypt the VISA number
received from the client, add the merchant id and stuff, and sent the
request back out to a connection site from the internet to the Visa
transaction (authorization) system again in a POS type of format. My guess is
that Netsites announcement about First Data Resources is where that
interconnect would happen as FDR processes for 30 million Visa cardholders to
the Visa Base network. (Look up first data (1dc.com) at internic!).
You have new mail.
>> Sounds the same as what happens with mail ordering via credit card to me. No
>> signature, the main check is that the credit card has not been reported lost
>> or stolen.
>However, the chance to use registered public keys is there. I
>thought perhaps Bank of America would make use of it, along
>with NetScape. I haven't seen much from the docs at mcom.com
>about how a person would go about using their own private key,
>rather than the session key that is agreed upon by the client
>and server.
[this is more a reply to the quote above, than to Rob]
In "real life" if your card is stolen or lost, you no longer have it:
it's not in your wallet, and you notice this. So you call up the credit
card company and cancel it, possibly before anyone uses it.
Telephones and networks are a bit different: now the risk is not that
someone will steal your card, but rather that someone will copy down
your card number. The card is still in your pocket, and you have no
reason to suspect any foul play until unexpected charges show up.
Here's the critical difference:
A thief who physically steals your card risks being caught
because you may report it missing before they use it. One who
copies your card number does not face this risk... you will not
report anything until AFTER they act.
Over a conventional telephone (not a cellular or cordless) this is
less of a problem: it isn't very likely that anyone will be able to
intercept your card number, in any way.
In a computer network there is a HUGE risk of someone intercepting your
card number. Even if you encrypt all of your transmissions, how can you
be sure that access to plaintext information is secure at both the
sending and receiving sites?
There are lots of programs out there that capture users passwords by
scanning memory for password strings... this is relatively annoying,
but generally it doesn't cost anyone MONEY. These same programs could
easily pick out credit card numbers by scanning memory that has not
been properly erased.
It doesn't matter HOW well you encrypt your transmissions if the attack
occurs before encryption and after decryption.
There are *HUGE* risks here, and I for one will not be using any digital
cash for many, many years.
Justin
--
<html><title>.signature</title><h1> Enhanced 911 Services </h1><hr><ul><li>
<a href="mailto:rjw...@undergrad.math.uwaterloo.ca"> Send me email. </a><li>
<a href="http://www.undergrad.math.uwaterloo.ca/~rjwells/911.html"> WWW page.
</a></ul><em> "One Policy, One System: Universal Service." </em></html>
Derek Harding
> [this is more a reply to the quote above, than to Rob]
>
> In "real life" if your card is stolen or lost, you no longer have it:
> it's not in your wallet, and you notice this. So you call up the credit
> card company and cancel it, possibly before anyone uses it.
>
> Telephones and networks are a bit different: now the risk is not that
> someone will steal your card, but rather that someone will copy down
> your card number. The card is still in your pocket, and you have no
> reason to suspect any foul play until unexpected charges show up.
>
knowledge, a risk which I consider fairly small but which still exists.
> Here's the critical difference:
>
> A thief who physically steals your card risks being caught
> because you may report it missing before they use it. One who
> copies your card number does not face this risk... you will not
> report anything until AFTER they act.
>
I do not follow this logic at all. It seems to imply that once a crime has
been committed the perpetrator can never be caught.
> Over a conventional telephone (not a cellular or cordless) this is
> less of a problem: it isn't very likely that anyone will be able to
> intercept your card number, in any way.
>
> In a computer network there is a HUGE risk of someone intercepting your
> card number. Even if you encrypt all of your transmissions, how can you
> be sure that access to plaintext information is secure at both the
> sending and receiving sites?
>
Why is this a HUGE risk? When you hand your card to the sales person or when
you give your card number over the phone for mailorder your card details are
noted down and often (in my experience) left lying around in plain view. With
this in mind why do you believe is it more likely that someone will go
through all the loops and obstacles to scan memory or break encryption when
they would not simply write down a number written clearly on a piece of paper?
> There are lots of programs out there that capture users passwords by
> scanning memory for password strings... this is relatively annoying,
> but generally it doesn't cost anyone MONEY. These same programs could
> easily pick out credit card numbers by scanning memory that has not
> been properly erased.
>
They could. How easily this could be performed will depend upon both computer
and physical security at both the client and server sites.
As an additional point where do you think your credit card details end up when
you mailorder something? On computers...just like they will for electronic
orders. Why therefore are you concerned with hacking of the electronic versions
and not the mailorder ones?
> It doesn't matter HOW well you encrypt your transmissions if the attack
> occurs before encryption and after decryption.
>
Quite true.
> There are *HUGE* risks here, and I for one will not be using any digital
> cash for many, many years.
>
Your choice. However so far I havent seen any well supported reasons why. I
sense a basic concern about security here. This fear may be well founded but the
arguments proposed so far most certainly are not.
Derek
--
Derek Harding de...@pipex.net
Product and Software Developer +44 1223 250422
PIPEX (The Public IP Exchange) http://www.pipex.net/people/derek/
James A. Nauer
Zusman) wrote:
> Right ... but this still involves a problem that may persist for quite
> a while:
>
> Let's say I am a small business that wants to use the Web to
> facilitate catalog orders. My Web server is connected to,
> say. BofA's validation system, and so I am guaranteed that CC
> numbers going between my system and BofA are safely encrypted.
>
> However, I advertise my home page, and people from all over the world
> connect to my home page. Presumably, these people will be using all
> sorts of different Web browsers: Lynx, Netscape, Mosaic, Web Explorer,
> etc. There will be differing releases of these browsers, too.
>
> So if some random person wants to place an order through my catalog
> and they are prompted for a credit card number, there is no guarantee
> that my software will be able to read the credit card number that is
> being sent from their client site to my server ... and if they are
> using the "wrong" version of client software, then they may have to
> send their CC number as plaintext. Many people may not want to do
> this, and this could hurt my business.
Non-SSL-aware clients won't be able to handle the "https://blah.blah" URL
in the form, so plaintext CC numbers won't be sent at all. This is
explained in the SSL inforamtion on NCom's server, and in postings that
Marc A. has already made in these groups.
For quite some time yet (at least 6 months, I would guess) you will need
to have some sort of fallback mechanism for users without secure browsers
on your Web pages--say, an 800 number to call--and you will need to
encourage customers to obtain secure clients. I would just put a line on
your pages like "If your browser cannot submit this form,
_download_a_copy_of_Netscape_". Problem solved.
--
James A. Nauer | "I shall not yield one whit of maturity,
Library Information | not grace, not respectibility, to the
Technologies | passing of time. I declare that I shall
Case Western Reserve Univ. | forever be, if not a child, certainly
(216) 368-MACS (368-6227) | childish" --Kennet Shardik
Jon Zeeff
>card number. Even if you encrypt all of your transmissions, how can you
Of course similar "HUGE" risks are present in giving your credit card
number over the phone or using it at your local restaurant. And yet
someone the whole credit card system works pretty well. Perhaps
"HUGE" is an exaggeration?
--
Commercial Internet Advertising, Marketing and Consulting
Jon Zeeff Branch Information Services j...@gw.branch.com
(313) 741-4442 http://branch.com/ gopher branch.com
Sima Desai
>>> signature, the main check is that the credit card has not been reported lost
>>> or stolen.
>In "real life" if your card is stolen or lost, you no longer have it:
>it's not in your wallet, and you notice this. So you call up the credit
>card company and cancel it, possibly before anyone uses it.
>Telephones and networks are a bit different: now the risk is not that
>someone will steal your card, but rather that someone will copy down
>your card number. The card is still in your pocket, and you have no
>reason to suspect any foul play until unexpected charges show up.
>Here's the critical difference:
> A thief who physically steals your card risks being caught
> because you may report it missing before they use it. One who
> copies your card number does not face this risk... you will not
> report anything until AFTER they act.
This risk is no different than the risk you take every time you throw away a
card receipt, or heck, use your card. You dont think that there's a risk
the cashier is copying down your card number and date and using it to mail
order stuff before you know it's stolen? There is. Happens all the time.
We are only talking about encryping the transfer of the card from the consumer
to the merchant -> replacing the physical process of handing your card to the
gas station attendant. Nothing else is being made any more or less secure.
David Brooks
> As in, if I find someone's credit card, I could use NetScape to
> send te number over the wire encrypted and now there's not even a
> signature to verify it's really the card holder.
I just ordered some goods using my American Express card -- over the
phone. Nobody remarked on my nice accent, either; I could have been
anybody.
I don't know if a flag would have gone up had the shipping address been
different from the billing address. The same holds true for e-plastic.
--
David Brooks dbr...@ics.com
Integrated Computer Solutions http://www.ics.com/~dbrooks/
Family values means waiting until *after* the cancer surgery, Newt?
Still married to first wife: Reagan no, Gingrich no, Limbaugh no, Clinton yes.
If Clinton *is* a draft-dodger, Gingrich *is* a druggie pornographer.
Lloyd Zusman
> In article <LJZ.94De...@panix.panix.com>, l...@panix.com (Lloyd
> Zusman) wrote:
>> Right ... but this still involves a problem that may persist for quite
>> a while:
>>
>> [ ... ]
>>
>> So if some random person wants to place an order through my catalog
>> and they are prompted for a credit card number, there is no guarantee
>> that my software will be able to read the credit card number that is
>> being sent from their client site to my server ... and if they are
>> using the "wrong" version of client software, then they may have to
>> send their CC number as plaintext. Many people may not want to do
>> this, and this could hurt my business.
> [ ... ]
> For quite some time yet (at least 6 months, I would guess) you will need
> to have some sort of fallback mechanism for users without secure browsers
> on your Web pages--say, an 800 number to call--and you will need to
> encourage customers to obtain secure clients. I would just put a line on
> your pages like "If your browser cannot submit this form,
> _download_a_copy_of_Netscape_". Problem solved.
Well, some people will indeed be computer literate, and running on
graphic-based systems where they can download and install their own
Web software. However, other users will be using Lynx on non-graphic
terminals. Some will be on MacIntoshes, some on Suns, some on HPUX
boxes, some on Amigas, some running under Windows, some on OS/2, some
on VMS, etc. etc. etc.
And many will be only marginally computer literate and using some kind
of canned software, and they wouldn't know how to install anything on
their machines.
The idea that each potential customer might have to find, download,
install, and probably even purchase secure client software will cause
many potential customers to remain non-customers.
I think an 800 number or something similar will be the only way to go
for such people, and I believe that this will represent a significant
percentage of the Web-connected customer base that many small
businesses will be targeting.
Over time this will slowly take care of itself. However, I think that
the following steps would have to take place before any reasonable
amount of Web-based CC business can be conducted ...
(1) A standard has to be agreed upon to be used by the major Web-browser
clients to send encrypted info such as CC numbers across the net to
servers, which also have to be using corresponding agreed-upon
decryption algorithms.
I see it taking months before there is an agreed-upon standard.
(2) This standard has to be designed into all the commonly used
client and server Web software.
I see another month or so before this happens.
(3) This software, especially the client software, has to be built
for all commonly used platforms and operating systems ... both
graphic and non-graphic versions.
Another month or so.
(4) The new, secure client software has to be disseminated to most
of the users who will be wanting it in order to make CC purchases.
This could take quite a while ... as much as a year or more.
And if step (4) costs money, then many potential customers will not
bother (at least not right away), thereby causing businesses which
want to rely upon Web-based CC sales to miss out on potential revenue.
I therefore think that it is in the interests of those people who wish
to go after Web-based CC business to make the following efforts:
(1) Push for standards of client-server encryption to get agreed upon
quickly.
(2) Push for these standards to quickly get compiled into all the major
httpd servers and Web browsers (graphic and non-graphic), for all
major platforms and operating systems.
(3) Make major efforts to get these new, secure Web browsers into the
hands of potential customers as soon as possible, free of
charge, and involving as painless an installation procedure
as is possible.
Is anyone interested in some of us joining together to start some sort
of "WWW Chamber of Commerce" or something similar, for the purpose of
taking on these tasks? ... if something like this doesn't already
exist.
Terry Lorz
: >In a computer network there is a HUGE risk of someone intercepting your
: >card number. Even if you encrypt all of your transmissions, how can you
: Of course similar "HUGE" risks are present in giving your credit card
: number over the phone or using it at your local restaurant. And yet
: someone the whole credit card system works pretty well. Perhaps
: "HUGE" is an exaggeration?
[ ...]
I agree. Anyone ever wonder why the Banks etc. are willing to absorb the
losses in credit card fraud? It is probably because of the 18 plus %
charged to cardholders who don't pay the outstanding balance every month.
We usually see one or two news stories a year about some bank eating a
fraud loss and basically nothing happens to the perpetrator. Like this
thread subtly points out, if you have a credit card, and have ever used
it, lots of folks have the number, from the store clerk, to the store to
the garbage man/woman who finds your paid bill stub in the trash.
The system works "pretty well" because we are willing to pay high
interest.
Terry
Rob Francis
>
> I just ordered some goods using my American Express card -- over the
> phone. Nobody remarked on my nice accent, either; I could have been
> anybody.
>
> I don't know if a flag would have gone up had the shipping address been
> different from the billing address. The same holds true for e-plastic.
Folks, I'm not wanting to go on about how things work today.
Yes, there are shortcomings in todays credit card system. Anyone
can do what Mr. Brooks just decribed, no problem. Fine. I
realize that. Not the best, but obviously the public has accecpted
it. It works.
MY POINT IS, there's a chance here to make it even better. Forcing
a person to using their own private key to encrypt their data
assures an identity. I'd love to see BoA take this possiblity and
run with it. I have no idea if they plan to or not. I haven't
heard from anyone at BoA or Mcom on it.
Please, let's not go on about how today's system works, let's talk
about where things are headed.
M. Hedlund
| Let's say I am a small business that wants to use the Web to
| facilitate catalog orders.
| I advertise my home page, and people from all over the world
| connect to my home page. Presumably, these people will be using all
| sorts of different Web browsers: Lynx, Netscape, Mosaic, Web Explorer,
| etc.
| [I]f they are using the "wrong" version of client software, then they
| may have to send their CC number as plaintext. Many people may not
| want to do this, and this could hurt my business.
Yes, and? Netscape Communications and MCC (perhaps among others) have
submitted proposals for a web-wide encryption standard. Those
proposals are being refined and reviewed. Do you expect Netscape
Comm. to blow off commercial web applications entirely until this
review process is complete? I really don't think that's what their
clientele (including my employer, though I am not speaking for the
company) wants -- they want to get this process moving while the net
is still on the cover of Newsweek.
I agree that an encryption standard should be usable by all clients;
but given that Netscape Comm. has published the method they've
implemented as a draft RFC, and given that their client is freely
downloadable by all of your potential customers, what more can you
expect them to do? It seems to me like they've gone to great lengths
in this case to avoid a blowup like the one in c.i.www.misc over their
HTML additions.
If your point is that the web/net is not yet the ideal commercial
environment, that's true. Commercialization, however, was not the
first aim of either the web or the net, and I think Netscape Comm. has
done what they can to ease the transition towards commercialization,
however desirable or lamentable you may see that transition.
/marc
t...@tms7808s.dukepower.com
<snip>
>If your point is that the web/net is not yet the ideal commercial
>environment, that's true. Commercialization, however, was not the
>first aim of either the web or the net, and I think Netscape Comm. has
>done what they can to ease the transition towards commercialization,
>however desirable or lamentable you may see that transition.
>
>/marc
Security and commercialization aside, who's going to trust their money to a
Windows app? What's going to happen when that beloved "GPF" pops up in the
middle of the transaction?
This is not a flame to the fine folks at Netscape, but I wouldn't *ANYTHING*
this serious to a Windows application.
Tom....
David MacRae
strong as those within the US. I believe tha Mcom are only allowed to ship
versions of Netscape/Netsite that support 40bit keys.
Does the Netscape that I can use outside the US cannot talk to a Netsite
server in the US ??
Dave
--
Dave MacRae FMA Ltd
Edinburgh Phone: 0131 551 4554
Scotland Fax: 0131 551 4772
justin wells
Derek Harding <de...@pipex.net> wrote:
>> Here's the critical difference:
>>
>> A thief who physically steals your card risks being caught
>> because you may report it missing before they use it. One who
>> copies your card number does not face this risk... you will not
>> report anything until AFTER they act.
>>
>I do not follow this logic at all. It seems to imply that once a crime has
>been committed the perpetrator can never be caught.
[deleted stuff]
>With this in mind why do you believe is it more likely that someone will go
>through all the loops and obstacles to scan memory or break encryption when
>they would not simply write down a number written clearly on a piece of paper?
Pls. bear with me. I am going to discuss credit card fraud as a way of
building up a case against EVER trusting a digital cash system that is
implemented on the Internet.
Here are the relevant points about credit card fraud:
- Accounts associated with stolen cards do not generally account for
a lot of fraud. Maybe the odd person steals or finds a card and tries
to exploit this, but organized crime rings see it as too much of a
risk to take.
- More typically stolen cards are combined with copied numbers. The
number of a valid card is reprinted onto a stolen card, and then the
fraud ring maxes out the card before the card company has a chance to
register the fraud. No risk in being caught WHILE DOING, all the risk
is in being caught by ANALYSIS after the fact.
- Thus the major tool credit card companies have in fighting card fraud
is ANALYSIS: they *love* analysis. They do statistical analysis of
the spending patterns of suspected card fraud rings in an attempt to
track something all the cases have in common. The search the paper
trail to find out who had access to what information, and then hand
the police a reasonable list of suspects to investigate.
- This analysis method is moderately successful. Card companies manage
to catch a few criminals this way. They lose a few BILLION dollars a
year to card fraud anyway, but they make a lot of money, and there is
enough deterrent in place to keep things from blowing up out of
control.
Here are the RISKS involved in card fraud under the current system:
- YES, as you say lots of people have access to your credit card. YES
it is in lots of computer systems. YES someone could copy your card
and get away with it. What they CANNOT get away with is copying a lot
of cards -- they will get caught by the paper trail and the analysis
which will eventually identify them as the common link.
Here is why Internet digital cash is dead in the water:
- Whereas corporate computers sit behind firewalls where the general
public cannot get at them, internet computers sit out in the public
where anyone with ten bucks can get at them. This is a HUGE difference.
- ANYONE can look at ANY packet that passes through their machine. You
may think you're safe because you have encrypted your email: good for
you. But how about all the people sniffing your packets between your
terminal server and your copy of PINE? Do they care that you've
encrypted it? NO! Lots of people rlogin or telnet in from one machine
to another to use their account -- many are not even aware this is
happening. For all you know your plaintext packets could be crossing
the whole damn country between your keyboard and the machine that you
are so cleverly encrypting your digital cash on.
- NO SYSTEM is secure. Especially not the big systems like Netcom that
so many businesses and people use: you KNOW that somewhere there is a
weak password, bug, or IP number that can be spoofed -- lots of trouble,
sure -- and not worth the bother usually. Who really wants to read
your email? But wait.. what if I can defraud you of $10,000 if I
go to this trouble? NOW who is interested?
- NO PAPER TRAIL. This is the big mama: NO PAPER TRAIL. NO ANALYSIS
can be done to find the common link. I sniff yer packets, and you
don't even know I saw them. No clue that I might have saw them: I am
just not in the equation, but I *am* into your wallet. So you identify
that there is a fraud ring with Netcom as the common link? There are
THOUSANDS of people on Netcom, and you don't even KNOW whether the
fraud took place at netcom, or at some site that netcom packets travel
through.
- EVEN IF you buy your own computer and set yourself up behind a firewall
so that you know damn well nobody can sniff your packets, look at your
account, or anything else -- how do you know that there isn't a big dork
sitting at the other end of the transmission? Maybe he's rlogging in
through 15 sites and half the net before he decrypts your transmission
to get at your digital cash. BINGO -- you're in fraud city, bigtime.
Nothing you can do but be a sucker.
The basic, fundamental concept of Internet is that it is an OPEN NETWORK,
and the basic, fundamental concept behind Unix, the driving force behind
Internet, is that it is an OPEN operating system. Sure people have hacked
things into it to make it secure, and it usually works...
But usually isn't good enough when there is a billion dollars worth of
risk free fraud waiting to be had.
The only reason there is so LITTLE hacking and cracking on the net right
now is that it isn't WORTH anything to do it. Unless you get some kind of
KICK out of getting into a system, what have you gained? NOT MUCH. So most
people who know how don't BOTHER.
Wait until they can make a profit at it....
Roy Smith
> I agree. Anyone ever wonder why the Banks etc. are willing to absorb the
> losses in credit card fraud? It is probably because of the 18 plus %
> charged to cardholders who don't pay the outstanding balance every month.
Not to mention the few % they pick up on the other side from the merchant
regardless of how quickly you pay your bill.
--
Roy Smith <r...@nyu.edu>
Hippocrates Project, Department of Microbiology, Coles 202
NYU School of Medicine, 550 First Avenue, New York, NY 10016
"This never happened to Bart Simpson."
Bill Arnett
>... Anyone ever wonder why the Banks etc. are willing to absorb the
> losses in credit card fraud? It is probably because of the 18 plus %
> charged to cardholders who don't pay the outstanding balance every month.
>...
Don't forget the 2% or 3% fee ON EVERY TRANSACTION that they charge to the
merchant (and which, of course, gets passed on to the customer).
--
Bill Arnett bi...@netcom.com
San Jose, CA "If it ain't broke, don't fix it!"
USA ftp://ftp.netcom.com/pub/bi/billa/billa.html
Bill Arnett
<rfra...@sf.psca.com> wrote:
>...
> MY POINT IS, there's a chance here to make it even better. Forcing
> a person to using their own private key to encrypt their data
> assures an identity. I'd love to see BoA take this possiblity and
> run with it. I have no idea if they plan to or not. I haven't
> heard from anyone at BoA or Mcom on it...
I agree 100%. My guess is that this is not being pursued for some
combination of the following reasons:
- the bankers don't understand public key encryption
- key management is a big hassle
- the cost of key management would be greater than the fraud losses (at
least in the short-term, which is all American business ever cares about)
- they want to approach comercializing the Net in stages and
authentication is not the first step
- the Forces of Darkness (e.g. NSA, DIA, CIA) have already won;
resistence is futile.
David Ehrens
transactions, I thought I'd offer my $.02 worth on the matter
as someone who was involved with automated teller machines
(ATM's). The way many of these systems work, even in a private
network, is by a complex exchange of keys so that the customer's
PIN number (or even an encrypted version) is never sent. In this
respect the communications are pretty secure. When I was
involved with Wells Fargo's ATM network, the worst problems were
usually drunks peeing on the deposit slips, muggings, and the
occasional fanatic who connected his truck winch to the ATM and
was chased down the highway dragging it behind. I would suspect
that the Netscape/BofA effort would work by key exchanges.
Kiosk mode will also involve making clients much more robust
than they are today.
--
David Ehrens, da...@iriscom.com
Lloyd Zusman
> Kiosk mode will also involve making clients much more robust
> than they are today.
What is "kiosk mode"?
Paul Prescod
You have new mail. <rjw...@undergrad.math.uwaterloo.ca> wrote:
>Rob Francis <rfra...@sf.psca.com> wrote:
>
>There are lots of programs out there that capture users passwords by
>scanning memory for password strings... this is relatively annoying,
>but generally it doesn't cost anyone MONEY. These same programs could
>easily pick out credit card numbers by scanning memory that has not
>been properly erased.
A secure OS would 0000000 memory before giving it to another process.
Admittedly if the other people use an insecure OS then you are screwed, but
perhaps you just have to check what OS and transaction software they are
using before sending your card number.
Or you could only send your credit card to a trusted third party who knows
about secure OSes and secure software.
Paul Prescod
Gunnar Rønning
> What is "kiosk mode"?
I believe it is a version running on a terminal whose only purpose is to
provide a WWW interface. Here at the University in Oslo with have some
Mac's with touchscreens running gopher in kioskmode. You have to provide a
high degree of security on kiosks, which is normally not required when
running the browser of some personal account.
Gunnar
--
Gunnar Rønning (gun...@ifi.uio.no) | WWW Homepage:
#include <std.disclaimer> | http://www.ifi.uio.no/~gunnarr/
Steve Driscoll
: >In a computer network there is a HUGE risk of someone intercepting your
: >card number. Even if you encrypt all of your transmissions, how can you
: Of course similar "HUGE" risks are present in giving your credit card
: number over the phone or using it at your local restaurant. And yet
: someone the whole credit card system works pretty well. Perhaps
: "HUGE" is an exaggeration?
I'm not sure I agree that this is a HUGE risk, but I will give a credit
card # over the phone to someone I called, but I will _NOT_ send my CC#
over the internet in today's environment. The main risk I see, and
this exists on phones if you're using a cordless and probably a cellular
phone is this: How many people, not related to your transaction, have
access to the stream of information? Further, how many people have the
means to locate and a CC# in this stream of information.
I beleive the set of people who could do this over the net is about
two or three orders of magnitude greater than for the phone system.
And in this case, there is no safety in numbers.
- Steve
J. Keith Pillow
>Jon Zeeff (j...@server.branch.com) wrote:
>: >In a computer network there is a HUGE risk of someone intercepting your
>: >card number. Even if you encrypt all of your transmissions, how can you
>: Of course similar "HUGE" risks are present in giving your credit card
>: number over the phone or using it at your local restaurant. And yet
>I'm not sure I agree that this is a HUGE risk, but I will give a credit
>card # over the phone to someone I called, but I will _NOT_ send my CC#
>over the internet in today's environment. The main risk I see, and
>this exists on phones if you're using a cordless and probably a cellular
>phone is this: How many people, not related to your transaction, have
>access to the stream of information? Further, how many people have the
>means to locate and a CC# in this stream of information.
You are living in a naive world. The cost of the equipment and skill level
required to snoop on phones is roughly the same cost of equipment and skill
level necessary to snoop on network traffic. And the number of people who
possess the access required and skill to do the deeds is about the same.
Remember: Most telephone traffic is transmitted via microwave. I know that
miles of fiber have been run in the US, and then there's still all that
copper, and we'd all like to believe that the wire running from our phones
connects us physically to the system, but really really the microwave is
still king in telecommunications. And it is damned easy to snoop.
But better than all this worrying is the knowledge that the majority of
stolen credit card numbers are obtained via dumpsters. Demand your carbons
and burn them.
I'm not advocating that work on secure net transactions should stop. I am
saying that a lot of net security people sound like fretful wretches, just as
a lot of the computer vira-phobes do. Use your head, find out about the
technology, (not just one side of it, if you are going to make comparisons),
and then act accordingly on the knowledge you have obtained. The risks of the
phone and net are roughly the same. But they are miniscule compared to the
risks posed by the dumpster diver! The criminal world is not going to go into
business scanning the net for CC numbers when they can get thousands of
numb-wits to get the numbers from the trash in greater quantities much cheaper.
|__|<eith____________ Pay no attention to that man behind the curtain|
|J. Keith Pillow |NSWC-Dahlgren Division |
|jpi...@relay.nswc.navy.mil |B20 Directed Energy Technology Group |
|My unofficial opinions only! |Dahlgren, Virginia 22448-5000 |
Rob Francis
> I agree 100%. My guess is that this is not being pursued for some
> combination of the following reasons:
> - the bankers don't understand public key encryption
> - key management is a big hassle
> - the cost of key management would be greater than the fraud losses (at
> least in the short-term, which is all American business ever cares about)
> - they want to approach comercializing the Net in stages and
> authentication is not the first step
I think the big one is that key registration is too difficult right
now. Along with the hassles of key management. I never said it'd
be easy, I'd like someone else to do it. (-:
Russell Nelson
>>BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
>>NETSCAPE COMMUNICATIONS SOFTWARE
You would have to setup a merchant account with the Bank before you
can do anything. You will also have to sign a merchant agreement with
the bank that will make sure that you make proper use of services
provided to you by the bank.
In other words, for all of us who are living in the 21st century
instead of just talking about it, this announcement is meaningless.
We still have all the same barriers to getting a merchant account.
However, First Virtual Holding Company <http://www.fv.com/> doesn't
require you to have a merchant account in order to sell information.
--
-russ <nel...@crynwr.com> http://www.crynwr.com/crynwr/nelson.html
Crynwr Software | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St. | +1 315 268 1925 (9201 FAX) | What is thee doing about it?
Potsdam, NY 13676 | What part of "Congress shall make no law" eludes Congress?
Phillip M. Hallam-Baker
In article <3c1272$a...@nntp1.u.washington.edu>, mi...@wavelet.apl.washington.edu (Mike Kenney) writes:
|>I'm curious about this as well, Netscape's secure protocol seems to
|>handle encryption and client authentication but not *user* authentication.
|>I know there is some commercial service out there that is authenticating
|>WWW transactions using PGP ... that seems like the way to go.
|>
|>To anyone at Netscape: Is there some reason to not use PGP sigs for
|>authentication?
There are many. PGP is designed mainly to get through mail systems in one
piece. HTTP is 8 bitclean and hence there is a lot less need for fussing about
with cannonicalisation etc.
Given the current generation of Credit card authentication schemes almost
anything is better. :-( Encrypting the transport layer is undoubtedly a kludge
and one of the reasons why everyone in the crypto community is a bit teed off
with the credit card people is that encrypting credit card numbers is the
only major application requiring encryption in a commodity browser. This
in turn gives us huge headaches with export licences. And at the end of the
day the security of the system of a whole is still pretty poor because the
`secret' information is the card number itself which the clerk at the other
end will have to see.
I don't see this lasting long though. The future of the credit card is some
sort of smart card with a secure signature system built into it. Then all we
need to do is to arrange the hardware interface to the pc in a cheap manner.
--
Phillip M. Hallam-Baker
Not Speaking for anyone else.
Phillip M. Hallam-Baker
|>Well, some people will indeed be computer literate, and running on
|>graphic-based systems where they can download and install their own
|>Web software. However, other users will be using Lynx on non-graphic
|>terminals. Some will be on MacIntoshes, some on Suns, some on HPUX
|>boxes, some on Amigas, some running under Windows, some on OS/2, some
|>on VMS, etc. etc. etc.
I'm suprised nobody pointed out that adopting a proprietary standard
developed outside the IETF open development process would have big implications.
|>(1) A standard has to be agreed upon to be used by the major Web-browser
|> clients to send encrypted info such as CC numbers across the net to
|> servers, which also have to be using corresponding agreed-upon
|> decryption algorithms.
|>
|> I see it taking months before there is an agreed-upon standard.
Alan Schiffman at EIT and myself have been working on this problem for
over a year. An agreement to merge the two resulting standards was made
two months ago at a meeting of the World Wide Web Consortium. The details
of this are currently being worked through.
|>(2) This standard has to be designed into all the commonly used
|> client and server Web software.
|>
|> I see another month or so before this happens.
I'm currently well into the integration of the common standard into the CERN
library.
|>(3) This software, especially the client software, has to be built
|> for all commonly used platforms and operating systems ... both
|> graphic and non-graphic versions.
|>
|> Another month or so.
Nope, the library is common to almost all Web browsers.
|>(4) The new, secure client software has to be disseminated to most
|> of the users who will be wanting it in order to make CC purchases.
|>
|> This could take quite a while ... as much as a year or more.
Doubt it, none of the other releases has.
|>And if step (4) costs money, then many potential customers will not
|>bother (at least not right away), thereby causing businesses which
|>want to rely upon Web-based CC sales to miss out on potential revenue.
|>
|>I therefore think that it is in the interests of those people who wish
|>to go after Web-based CC business to make the following efforts:
|>
|>(1) Push for standards of client-server encryption to get agreed upon
|> quickly.
What would you prefer, fast agreement or a standard that works? This is not
exactly trivial stuff you know. Nobody involved wants to be the person who
invented the broken standard. Releasing code and calling it "bullet-proof" in
this area is "brave".
The standard does not pass until three things happen, first the authors are
happy with it, second the referees are happy with it, third the Web community
is happy with it.
Bar minor wrangling over the naming of tags and exact byte formats we have
finished this one.
|>(2) Push for these standards to quickly get compiled into all the major
|> httpd servers and Web browsers (graphic and non-graphic), for all
|> major platforms and operating systems.
Not a problem, working on it. Ie like if I wasn't in this window I would be
hacking the autoconfigure script.
|>(3) Make major efforts to get these new, secure Web browsers into the
|> hands of potential customers as soon as possible, free of
|> charge, and involving as painless an installation procedure
|> as is possible.
EIT released their version of the standard in Alpha test several months ago.
|>Is anyone interested in some of us joining together to start some sort
|>of "WWW Chamber of Commerce" or something similar, for the purpose of
|>taking on these tasks? ... if something like this doesn't already
|>exist.
Try Commercenet.
Finaly a few points about the IETF process:-
1) For standards track status the development must have been open.
2) There have to be two independent implementations.
3) For crypto stuff there has to be a non-US version [not sure if this is a
formal requirement].
The only proposal that I am aware of that meets these requirements is the
S-HTTP/Shen proposal. [OK we don't meet 2 quite yet, that's because I'm
not quite finished yet].
Actually here, have to distinguish between shen the specification and shen
the implementation. The latter is separate.
Karl Renaut
: I think this might be interesting to readers of these groups...
: Cheers,
: Marc
: BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
: NETSCAPE COMMUNICATIONS SOFTWARE
[snip marketing hype]
Hey don't pull your arm out of its socket patting yourself on the back!
Don't get me wrong, I think NetScape is doing great, selling software that
isn't even done yet! Wow, you guys wanna let us in on your secret? All
kidding aside, congratulations.
--
-----------------------------------------------------------------
Karl Renaut Voice: 904-886-2908
Southeast Network Services Data: 904-292-4567
P.O. Box 56946 email: kre...@jaxnet.com
Jacksonville, FL 32241 / - \
----------------------------------------m| o o |m----------------
U
Karl Renaut
: >BANK OF AMERICA TO PROVIDE SECURE PAYMENT SYSTEM OVER INTERNET USING
: >NETSCAPE COMMUNICATIONS SOFTWARE
: Interesting, I'm curious (if it's public information), will Bank
: of America only be offering the ability to send a card number
: over the wire encrypted, not really doing authentication of the
: client?
This is standard operating procedure for mail order / phone order
companies.
: As in, if I find someone's credit card, I could use NetScape to
: send te number over the wire encrypted and now there's not even a
: signature to verify it's really the card holder. Unless Bank of
: America is going to be registering public keys, but the release read
: like it's just encrypted using the session key and nothing more.
Of course you can, as long as the card holder has not reported his card
as lost or stolen. Be careful where you send the merchandise, there might
be a policeman waiting for you at the mail box :-)
: Just curious.
: -rob
: ---
: Rob Francis
: Paradigm Systems http://www.sf.psca.com
: Rob_F...@sf.psca.com
Marc VanHeyningen
>In article <3c1272$a...@nntp1.u.washington.edu>, mi...@wavelet.apl.washington.edu (Mike Kenney) writes:
>|>To anyone at Netscape: Is there some reason to not use PGP sigs for
>|>authentication?
>
>There are many. PGP is designed mainly to get through mail systems in one
>piece. HTTP is 8 bitclean and hence there is a lot less need for fussing about
>with cannonicalisation etc.
Actually, PGP's transport encoding (or "ascii armor" as it is dubbed
for some strange reason) is mostly orthogonal. I'd say there are much
better reasons, like the spec, the fact that its symmetric cipher is
not and cannot be made exportable from the U.S., and the fact that I
don't think it's possible to get a copy of PGP in Europe which is
licensed for commercial use.
>I don't see this lasting long though. The future of the credit card is some
>sort of smart card with a secure signature system built into it. Then all we
>need to do is to arrange the hardware interface to the pc in a cheap manner.
Not until losses from fraud are substantially higher than the cost of
implementing this system. Determing how we can hasten this day is
left as an exercise to the reader. :-)
--
Marc VanHeyningen <URL:http://www.cs.indiana.edu/hyplan/mvanheyn.html>
Martin Glassborow
: bi...@netcom.com (Bill Arnett) wrote:
: > I agree 100%. My guess is that this is not being pursued for some
: > combination of the following reasons:
: > - the bankers don't understand public key encryption
: > - key management is a big hassle
: > - the cost of key management would be greater than the fraud losses (at
: > least in the short-term, which is all American business ever cares about)
: > - they want to approach comercializing the Net in stages and
: > authentication is not the first step
: I think the big one is that key registration is too difficult right
: now. Along with the hassles of key management. I never said it'd
: be easy, I'd like someone else to do it. (-:
Key registration is indeed a nightmare but please give us techies out there
who work for banks a chance (and some credit!). We do understand public key
encryption and we do understand key management (although on a slightly
smaller scale than what is going to happen in the future). We're working
on it and although authentication isn't the first step, its right up there.
Martin
John Waycott
>
[snip]
>
> The basic, fundamental concept of Internet is that it is an OPEN NETWORK,
> and the basic, fundamental concept behind Unix, the driving force behind
> Internet, is that it is an OPEN operating system. Sure people have hacked
> things into it to make it secure, and it usually works...
>
> But usually isn't good enough when there is a billion dollars worth of
> risk free fraud waiting to be had.
>
> The only reason there is so LITTLE hacking and cracking on the net right
> now is that it isn't WORTH anything to do it. Unless you get some kind of
> KICK out of getting into a system, what have you gained? NOT MUCH. So most
> people who know how don't BOTHER.
>
> Wait until they can make a profit at it....
>
Perhaps a major fraud case on the internet will finally spur the
banks into really doing something about it. As it stands, they
have no incentive to do anything. Their customers enjoy the
convenience of the credit card system as it is, and the banks
are making a profit, so why make things more difficult?
As far as security goes, I agree that encrytping a transaction
on a computer which you have no control over is a weak solution.
What makes it even more dangerous is that many internet users
don't have a clue as to how their data is moved around.
I think the only viable solution in the long term is
some sort of smart card system where the card itself would
encrypt the transaction.
Andrew Gideon
>
> [...]
>
>Is anyone interested in some of us joining together to start some sort
>of "WWW Chamber of Commerce" or something similar, for the purpose of
>taking on these tasks? ... if something like this doesn't already
>exist.
>
(Hi, Lloyd!)
Isn't this what CommerceNet was intended to be?
- Andrew
---
-----------------------------------------------------------
| Andrew Gideon | TAG Systems inc. |
| Consultant | Suite 333 |
| | 41 Watchung Plaza |
| Tel: (201) 783-5583 | Montclair, N.J. 07042 |
| Fax: (201) 783-5334 | |
| and...@tagsys.com | http://www.tagsys.com/ |
-----------------------------------------------------------
Lloyd Zusman
> In article 94Dec7...@panix.panix.com, l...@panix.com (Lloyd Zusman) writes:
>>
>> [...]
>>
>> Is anyone interested in some of us joining together to start some sort
>> of "WWW Chamber of Commerce" or something similar, for the purpose of
>> taking on these tasks? ... if something like this doesn't already
>> exist.
>>
> (Hi, Lloyd!)
(Hi Andy!)
> Isn't this what CommerceNet was intended to be?
I don't know ... I don't know much about CommerceNet's charter: is
CommerceNet an advocate or lobbyist for the interests of Web-based
businesses, in addition to being a central, known location to place
ads?
Is CommerceNet doing anything to promote the speedy development
browser-to-httpd encryption and security standards, or to disseminate
compliant browsers to potential customers once these standards are
agreed upon?
Andrew Gideon
>In article <1994Dec12.0...@tagsys.com>, and...@tagsys.com (Andrew Gideon) writes:
>
>> In article 94Dec7...@panix.panix.com, l...@panix.com (Lloyd Zusman) writes:
>>>
>>> Is anyone interested in some of us joining together to start some sort
>>> of "WWW Chamber of Commerce" or something similar, for the purpose of
>>> taking on these tasks? ... if something like this doesn't already
>>> exist.
>
>
>I don't know ... I don't know much about CommerceNet's charter: is
>CommerceNet an advocate or lobbyist for the interests of Web-based
>businesses, in addition to being a central, known location to place
>ads?
>
>Is CommerceNet doing anything to promote the speedy development
>browser-to-httpd encryption and security standards, or to disseminate
>compliant browsers to potential customers once these standards are
>agreed upon?
>
My understanding is that CommerceNet was to be all of these things.
However, despite being a member (of some low level, admittedly), I
don't know that any of these things are taking place.
We recently tried to learn about what CommerceNet has done with
respect to encryption. It was for this reason that we originally
joined. Unfortunately, we merely got a pointer elsewhere, with
no other useful information (except that, despite our membership,
we'd still have to purchase it when/if it actually exists).
To be honest, I have no idea what we got for our money, and we'll
be giving it serious (re)consideration next year.
Michael Landeros
number is foolish. Someone out there should devise a thumb print scanner
or similar device that would accompany the number. That would take care of
the "authentication of the client issue."
Mike L.
David J. Bianco
Or create a big market for severed thumbs....
--
=============================================================================
David J. Bianco Chair, NASA Webmasters Working Group
Computer Sciences Corporation, http://ice-www.larc.nasa.gov/webmasters/
NASA Langley Research Center Personal Info:
<d.j.b...@larc.nasa.gov> http://www.larc.nasa.gov/~bianco/bianco.html
Brett Kappenman
People already order stuff through the mail with a CC number. You
order stuff on television with a CC number via the telephone. Seems
to me there isn't that much difference between that and sending it
electronically.
My $.02.
Brett
Jim Phillips
>People already order stuff through the mail with a CC number. You
>order stuff on television with a CC number via the telephone. Seems
>to me there isn't that much difference between that and sending it
>electronically.
You're right, there isn't that much difference between calling in your
credit card number to a company and sending it over the internet in email.
The problem is, with this small difference, you can lose your number.
Someone could wiretap the phone of the company you're calling in to, and
the person could get your card number. It's possible. However, it's not
very likely, since the person would have to listen to all the phone
conversations to get a lot of numbers.
Someone on the net, with the properly placed router and/or sniffer, could
gather a lot more if they 'tapped' the input into a company that accepted
card numbers through the net. It would be a lot easier on the person
trying to get the numbers too, because they wouldn't have to look at each
individual message manually. All it would have to do is search the messages
with a program (if they're smart enough to 'tap' into the net this way,
they're more than smart enough to make this type of sifting program).
Encryption is the only way to make the card semi-theftproof. The problem
is that encryptions can be broken, stolen, or sold by their creators. Who
would sell encryption decoding? How about the guy who didn't get the raise,
bonus or promotion he was promised? There's just too many loopholes right
now for me to trust the net for sensitive information.
Jim
Lloyd Zusman
The difference is one of scale. When you give someone a CC number
over the telephone, there is one person at the other end with your CC
number. Perhaps one or two others at that end may also view it.
When you send an non-encrypted CC number over the net, you still have
the couple of people at the other end of your transaction potentially
viewing your CC number, *plus* how ever many other thousands of people
are sitting on the net with sniffers, looking for CC numbers shooting
around all over the place.
It's equivalent to giving out your CC number over a phone line that
you suspect may be tapped by thousands of different people.
Ranbir Chawla
Phillips) wrote:
> Brett Kappenman <br...@halcyon.com> wrote:
[various forms of usage etc...
> Encryption is the only way to make the card semi-theftproof. The problem
> is that encryptions can be broken, stolen, or sold by their creators. Who
> would sell encryption decoding? How about the guy who didn't get the raise,
> bonus or promotion he was promised? There's just too many loopholes right
> now for me to trust the net for sensitive information.
>
>
Jim,
If you think that the kid at Radio Shack hasn't looked at your gold card
and thought about that trip to Aruba, you are living in a very comfortable
'reality distortion field'. Or how 'bout the guys at that car dealership
in Jersey who took social security numbers, accessed the customers credit
reports, took the numbers of the report and rang up zillions in fraud.
The problem is that as hackers we know how we could get in and steal the
numbers off the net, what we forget is that there are ways in 'real' world
too, and people do it all the time.
Solutions? A more sophisticated pin number system (i mean realy, 4 digits
;-), maybe built on a digital signature system. Basically if the law was
structured to leave the liablity for security breaks soley in the hands of
the credit card companies you have nothing to worry about. And that my
friends is the real issue.
Oh, have a great 1995 folks.
------------------------------------------------------------------------------
Ranbir Chawla "Peace on Earth is Good
President Powder on Earth is Better!.."
Virtual Solutions, Inc.
Littleton, CO in...@vsinet.com ------------------------------------------------------------------------------
Stephen Lord
Or you could just collect the garbage from the back of any store and pick
up thousands of the things... whihc is apparently the way most thieves do
it anyway... The simple solution is to only send goods to the mailing
address registered with the card provider..
Steve
Chris Schefler
> When you send an non-encrypted CC number over the net, you still have
> the couple of people at the other end of your transaction potentially
> viewing your CC number, *plus* how ever many other thousands of people
> are sitting on the net with sniffers, looking for CC numbers shooting
> around all over the place.
> It's equivalent to giving out your CC number over a phone line that
> you suspect may be tapped by thousands of different people.
It would take quite a feat of engineering to break into an Internet
backbone on the phone network and sniff out credit cards. Anybody
with that kind of technical ability can earn hundreds of thousands
of dollars a year in the industry; why would they need to pilfer
from credit cards?
Yes, it can and probably will happen. But the amount of Internet
CC fraud will be a tiny fraction of all CC fraud, I predict. The
biggest threat will remain physical theft of your card by petty
thieves.
But the public demands it, so encryption will become standard.
I think the big scare of credit card transaction vulnerability on the
net is hyperbole, but I'm glad we're getting encrypted communications
(I think).
Lloyd Zusman
> Lloyd Zusman (l...@panix.com) wrote:
>> When you send an non-encrypted CC number over the net, you still have
>> the couple of people at the other end of your transaction potentially
>> viewing your CC number, *plus* how ever many other thousands of people
>> are sitting on the net with sniffers, looking for CC numbers shooting
>> around all over the place.
>> It's equivalent to giving out your CC number over a phone line that
>> you suspect may be tapped by thousands of different people.
> It would take quite a feat of engineering to break into an Internet
> backbone on the phone network and sniff out credit cards. Anybody
> with that kind of technical ability can earn hundreds of thousands
> of dollars a year in the industry; why would they need to pilfer
> from credit cards?
It's not necessary to electronically sniff the backbone. Any machine
on the net can be configured as a packet sniffer to capture any
and all packets flowing through the segment of the net that the
particular machine resides on.
I'm running on a SunOS 4.1.3 system, and there is a utility called
'etherfind' which does just this. You have to have 'root' privileges
to run this program, but all that means is that an unscrupulous sysop
or a hacker who has gained 'root' access can monitor packet traffic on
the net segment that the machine resides on.
Once the packets are being captured, it's relatively easy to search
through them for text that looks like CC numbers.
People who are able to get through the security at well-trafficked net
sites (such as netcom, to name one which has had recent security
difficulties) would be able to view lots of packets, and if people
were routinely sending CC numbers over the Web, many of these CC
numbers could potentially be "captured".
James HG Redekop
>Lloyd Zusman (l...@panix.com) wrote:
>
>> It's equivalent to giving out your CC number over a phone line that
>> you suspect may be tapped by thousands of different people.
>
>It would take quite a feat of engineering to break into an Internet
>backbone on the phone network and sniff out credit cards.
I think Lloyd was referring to a software sniffer, not a hardware tap.
Ethernet sniffers are very easy to come by -- there's one in the alt.2600
FAQ. It sits in the background and watches any info that passes through.
--
James H.G. Redekop
tz...@publix.empath.on.ca
tz...@csd.uwo.ca
http://www.csd.uwo.ca/~tzoq/ <-- It's here! Check out The Residents.
Ed Thomson
>>It would take quite a feat of engineering to break into an Internet
>>backbone on the phone network and sniff out credit cards.
> I think Lloyd was referring to a software sniffer, not a hardware tap.
> Ethernet sniffers are very easy to come by -- there's one in the alt.2600
> FAQ. It sits in the background and watches any info that passes through.
Assuming he was, don't you think that the backbone sites are a little more
secure than that (well, all except Netcom ;)); secure enough that somebody
couldn't hack root on them and install a packet sniffer?
--
Ed - etho...@uiuc.edu - http://ux1.cso.uiuc.edu/~ethomson/home.html
Derick Gonzalez
Actually, Lloyd, etherfind only works on your local physical
ethernet. Assuming that routers and gateways are appropriately configured
(which they are for the bulk of the time), the bulk of IP traffic will
never be sent your way. If there is a chance of CC pilferage, it would
most likely come from within either of the two transaction endpoints, i.e.
someone on your net, or someone on the vendor's net. This is completely
analogous to having your roommate snitch your CC#, or someone on the
other end of the Home Shopping Club being careless.
---
+----------------------------------------------------------------------------+
| Derick R. Gonzalez | ________ |
| Department of High Engery Physics | \ / |
| California State University | \ / |
| dq...@interramp.com | \ / |
| 1247 N. Sweetzer Ave #2, W. Hollywood CA 90069 |29c \/ |
+----------------------------------------------------------------------------+
| It is better to be hated for what one is, than loved for what one is not. |
| (A. Gide) |
+----------------------------------------------------------------------------+
Jon Tara
>From: phil...@teleport.com (Jim Phillips)
>Subject: Re: FYI -- Bank of America and Netscape
>Date: Fri, 30 Dec 94 19:26:54 GMT
>Encryption is the only way to make the card semi-theftproof. The problem
>is that encryptions can be broken, stolen, or sold by their creators. Who
>would sell encryption decoding? How about the guy who didn't get the raise,
>bonus or promotion he was promised? There's just too many loopholes right
>now for me to trust the net for sensitive information.
Guess you haven't kept up with advances in crypto systems over the past 15
years or so. The technology being used is public-key, and doesn't depend on a
secret key shared by the sender and receiver. They aren't repeating the
mistakes of the cable industry here.
(Many cable systems - at least in the past - use encryptation where each box
uses the SAME encryptation key. When the system is compromised, either the
system is permanently broken, or in newer systems, they send out a code card
to everybody. The stupidy of the cable industry never ceases to amaze me...)
________________________
A new picture of San Diego Bay every half hour:
<A HREF ="http://www.cts.com/~jtara/baycam.html">San Diego BayCam</A>
jt...@cts.com
James HG Redekop
Ed Thomson <etho...@uiuc.edu> wrote:
>tz...@csd.uwo.ca (James HG Redekop) writes:
>> I think Lloyd was referring to a software sniffer, not a hardware tap.
>> Ethernet sniffers are very easy to come by -- there's one in the alt.2600
>> FAQ. It sits in the background and watches any info that passes through.
>
>Assuming he was, don't you think that the backbone sites are a little more
>secure than that (well, all except Netcom ;)); secure enough that somebody
>couldn't hack root on them and install a packet sniffer?
I *hope* that they are, but I don't count on it. I've followed some hacker-
hunting my SO has done, and one comes across some rather alarming security
holes at times.
Besides, it doesn't have to be on a backbone. Set up a sniffer on an internet
mail-order company's machine, and you'll have access to *lots* of CC
numbers if they aren't encrypted.
Paul Gilmartin
: Guess you haven't kept up with advances in crypto systems over the past 15
: years or so. The technology being used is public-key, and doesn't depend on a
: secret key shared by the sender and receiver. They aren't repeating the
: mistakes of the cable industry here.
: (Many cable systems - at least in the past - use encryptation where each box
: uses the SAME encryptation key. When the system is compromised, either the
: system is permanently broken, or in newer systems, they send out a code card
: to everybody. The stupidy of the cable industry never ceases to amaze me...)
Public-key systems are notoriously _s_l_o_w_. So slow, in fact, that
they generally rely on using the public key to transmit a randomly
chosen key for a single-key system, which is then used to encrypt the
rest of the message. That key is used for only one message, then
discarded.
Suppose you encrypt the bulk of the program material with a single
key, then encypt that key with each subscriber's public key. You
change the key frequently enough to discourage pilferers' transmitting
the key.
Plug in some numbers. Say a million subscribers. Change the key
hourly. Have you the bandwidth to re-encrypt and transmit the key?
And this ignores the possibility of a consipracy of users who will
choose a key-pair solely for the purpose of pilfering programs.
They will be willing to share that private key among themselves.
Public-key systems presume the holder of the private key is
motivated to keep it private -- program pilferers have quite the
contrary motivation.
-- gil
Lloyd Zusman
> In article <LJZ.95Ja...@panix.panix.com>, l...@panix.com (Lloyd Zusman) writes:
> |>
> |> I'm running on a SunOS 4.1.3 system, and there is a utility called
> |> 'etherfind' which does just this. You have to have 'root' privileges
> |> to run this program, but all that means is that an unscrupulous sysop
> |> or a hacker who has gained 'root' access can monitor packet traffic on
> |> the net segment that the machine resides on.
> |>
> Actually, Lloyd, etherfind only works on your local physical
> ethernet. Assuming that routers and gateways are appropriately configured
> (which they are for the bulk of the time), the bulk of IP traffic will
> never be sent your way. If there is a chance of CC pilferage, it would
> most likely come from within either of the two transaction endpoints, i.e.
> someone on your net, or someone on the vendor's net. This is completely
> analogous to having your roommate snitch your CC#, or someone on the
> other end of the Home Shopping Club being careless.
... or one of your 30,000 "roomates" at netcom watching all the
traffic going in and out of that site, which is quite doable with
'root' privileges and 'etherfind'. I still think that this is an
issue of scale. Even on a single Internet provider's site there are
lots more opportunities for CC capture than among a person's
housemates and the people he or she does business with.
--
Lloyd Zusman 01234567 <-- The world famous Indent-o-Meter.
David Kammeyer
: Encryption is the only way to make the card semi-theftproof. The problem
: is that encryptions can be broken, stolen, or sold by their creators. Who
Well after about 20 years, RSA has yet to be broken.
: would sell encryption decoding? How about the guy who didn't get the raise,
Hmmm, well, I can decrypt anything I have a key for with PGP... But
until someone breaks RSA (which probably will never happen, except for
brute force, which would require an enormous ammount of horsepower) there
is NO way to break it unless you have the person's private key.
: bonus or promotion he was promised? There's just too many loopholes right
With proper security measures, noone ever has to have access to the key
except root on that system. You should be more worried about the cashier
at your local grocery store writing down numbers for extra
cash.
: now for me to trust the net for sensitive information.
Suit yourself, but don't go around spreading misinformation.
--
--------------------------------------------------------------------------
David Kammeyer kamm...@interaccess.com
"The general public is a |This sig has 1,000,000 viewers per month -
pretty stupid person" - Me |*YOU* should be advertising here!
--------------------------------------------------------------------------
Jim Phillips
>Jim Phillips (phil...@teleport.com) wrote:
>
>: Encryption is the only way to make the card semi-theftproof. The problem
>: is that encryptions can be broken, stolen, or sold by their creators. Who
>
>Well after about 20 years, RSA has yet to be broken.
Correction: After about 20 years, RSA is not KNOWN to be broken. Big difference.
If I had broken a major encryption scheme and were to use it, I sure wouldn't
advertise that I had broken it. I'd save it up and use it for maximum profit.
>
>: would sell encryption decoding? How about the guy who didn't get the raise,
>
>Hmmm, well, I can decrypt anything I have a key for with PGP... But
>until someone breaks RSA (which probably will never happen, except for
>brute force, which would require an enormous ammount of horsepower) there
>is NO way to break it unless you have the person's private key.
Enigma (WWII, Germany) was break-proof, too. As far as enormous amounts of
horsepower, you can now buy a cheap Pentium or PowerPC for under $2,000.
Get a hundred of these, network them together, and program them to work
on the problem together. Of course this is not a trivial matter, and chances
are won't be done to get credit card information. However, it is possible
to do, given the current technology.
While at school, I was told a story of how a company advertised that they
had created a encryption that was impossible to break. I was also told
that when a computer expert found out about it, he networked all his company
computers to work on the problem, and had it figured out in less than a month.
I don't know if this story was based on fact or not; I'd like to get the
details if someone has them.
>
>: bonus or promotion he was promised? There's just too many loopholes right
>
>With proper security measures, noone ever has to have access to the key
>except root on that system. You should be more worried about the cashier
>at your local grocery store writing down numbers for extra
>cash.
Why should root have to access the key? Granted, the people with root access
(probably) make more money and would have more to lose than than a grocery
clerk, but why give them the chance? As long as people are involved, there's
always the risk.
>: now for me to trust the net for sensitive information.
>
>Suit yourself, but don't go around spreading misinformation.
Please point to the misinformation in my post.
Jon Tara
>From: p...@sanitas.stortek.com (Paul Gilmartin)
>Subject: Re: FYI -- Bank of America and Netscape
>Jon Tara (jt...@cts.com) wrote:
>: (Many cable systems - at least in the past - use encryptation where each
box >: uses the SAME encryptation key. When the system is compromised, either
the >: system is permanently broken, or in newer systems, they send out a code
card >: to everybody. The stupidy of the cable industry never ceases to amaze
me...)
>Public-key systems are notoriously _s_l_o_w_. So slow, in fact, that
>they generally rely on using the public key to transmit a randomly
>chosen key for a single-key system, which is then used to encrypt the
>rest of the message. That key is used for only one message, then
>discarded.
Yes, this is generally how it is used. Irrelevent.
>Suppose you encrypt the bulk of the program material with a single
>key, then encypt that key with each subscriber's public key. You
>change the key frequently enough to discourage pilferers' transmitting
>the key.
Of course, program material is not encrypted - the processing power to do that
has not been available until just recently. What *is* (or should be)
encrypted are commands to decoder boxes. These are addressed individually
already, so the overhead to encrypt these commands is minimal.
Most cable-box spoofs involve sending "fake" commands to the box. The
pirate adds a circuit board that generates signals that the box thinks it
is receiving from the cable company. This wouldn't be possible if public-key
with digital signatures were used.
>Plug in some numbers. Say a million subscribers. Change the key
>hourly. Have you the bandwidth to re-encrypt and transmit the key?
See above. Program material isn't encrypted.
>And this ignores the possibility of a consipracy of users who will
>choose a key-pair solely for the purpose of pilfering programs.
>They will be willing to share that private key among themselves.
>Public-key systems presume the holder of the private key is
>motivated to keep it private -- program pilferers have quite the
>contrary motivation.
>-- gil
________________________
Remco Treffkorn
Right! All I hear is: If someone has the criminal energy *and* the I.Q.
*and* the equipment *then* he can make alot of money.
Well, most people that have the machienery (or access to it) and the I.Q.
don't have to be criminals to make a good living.
OTOH, somebody with the criminal energy but neither I.Q. or high tech can
just use a .45 to convince most people to give 'em all they have.
This thread has become rather idiotic. Sure it *can* be done, but what is
the probability that *I* will be a victim?
You guys better don't use airplanes. They are so 'unsafe'!
Better stay at home at the 13th...
Did anybody think about where the liability lies when fraud is being
commited with your credit card number? It's done all the time, and if
you are not a complete retard, then your issuer will eat the loss.
I think, the chance that you will be out of a job by the end of the
month is much more 'real'. Do you have a plan 'B' for that?
Ignoring problems does not solve them, but blowing 'em out of proportion
only makes for boring conversation.
Besides, the half truths and superstitions I saw here just make the mind
boggle. Why don't you talk about something you understand?
My apologies to the two people who new what they were talking about!
And before I get sh!t about the misconfigured news reader:
my e-mail is re...@emc.rvt.com at EMC.
A happy new year to all of you.
Remco
And yes, I feel better now ;-)
Jeremy Doig
phil...@teleport.com writes:
>Enigma (WWII, Germany) was break-proof, too. As far as enormous amounts
of
>horsepower, you can now buy a cheap Pentium or PowerPC for under $2,000.
>Get a hundred of these, network them together, and program them to work
>on the problem together.
Before wildly speculating any more, you should all go read:
http://home.mcom.com/info/SSL.html
If I could afford 100 * PowerMacs, I would set up a render farm.
Jeremy
Ed Thomson
>Well, most people that have the machienery (or access to it) and the I.Q.
>don't have to be criminals to make a good living.
>This thread has become rather idiotic. Sure it *can* be done, but what is
>the probability that *I* will be a victim?
It's quite probable, really. Most people with the IQ and the equipment
*will* do it, just for the sake of doing it. You must not understand
computer scientists very well. Most computer scientists will do anything,
just to see if it can be done. There are probably a few that would sell
it (I probably would). And like everything else, it would fall into the
wrong hands and the criminals would end up with it. Then you're a victim.
Eventually, a better encryption algorithm comes along, and the process
starts over.
Neal Dalton
: Brett Kappenman <br...@halcyon.com> wrote:
: >People already order stuff through the mail with a CC number. You
: >order stuff on television with a CC number via the telephone. Seems
: >to me there isn't that much difference between that and sending it
: >electronically.
: You're right, there isn't that much difference between calling in your
: credit card number to a company and sending it over the internet in email.
: The problem is, with this small difference, you can lose your number.
You can on a cordless phone or tabbing on lines.
: Someone could wiretap the phone of the company you're calling in to, and
: the person could get your card number. It's possible. However, it's not
: very likely, since the person would have to listen to all the phone
: conversations to get a lot of numbers.
Yes. How about if they just listen to the companies taking orders?
What about the CC validation lines?
: Someone on the net, with the properly placed router and/or sniffer, could
: gather a lot more if they 'tapped' the input into a company that accepted
: card numbers through the net.
That is most likely in the phone company. Long distance carriers
provide the T1-T3 lines that make up the back bone. It is the same
type of lines the backbone of the 800 number use.
I don't think you can just hook a PC up to it and sniff.
: It would be a lot easier on the person
: trying to get the numbers too, because they wouldn't have to look at each
: individual message manually. All it would have to do is search the messages
: with a program (if they're smart enough to 'tap' into the net this way,
: they're more than smart enough to make this type of sifting program).
You smart enouph to break into the database of the phone ordering system.
They could also if they record the calls. Of course the could just
break into the computer ordering system. Or just tape into the
validation company and convert that.
The law are the same in this case and just as hard to tap into.
: Encryption is the only way to make the card semi-theftproof. The problem
: is that encryptions can be broken, stolen, or sold by their creators. Who
: would sell encryption decoding? How about the guy who didn't get the raise,
: bonus or promotion he was promised? There's just too many loopholes right
: now for me to trust the net for sensitive information.
I could also pay off a phone employee to breaking to the phone system.
There's just too many loopholes. The phone system is a majority of the
computer network. There is usually 2 ends your and theirs that are
susceptible. Do you trust your end? There end is no different than the
phone calls.
Do you know how the validation of CC are done? Many are over phone
lines. Are there encrypted?
Neal
Jon Tara
>From: re...@myhost.subdomain.domain (Remco Treffkorn)
>Subject: Re: FYI -- Bank of America and Netscape
>Ed Thomson (etho...@uiuc.edu) wrote:
>: re...@myhost.subdomain.domain (Remco Treffkorn) writes:
>With all due respect sir, you are an idiot.
>The best preventer of crime is people with scrouples.
>The guy you sell the idea to must be even stupider than you are, else he
>would not take the risk. Since he is so stupid, he will get caught. He will
>spill his guts to the DA, just to get is sentence reduced. You will
>occupy the cell next to his.
>Grow up and get a life!
FWIW, the person you're flaming has, literally, yet to grow up. He's still in
high school and works part time for NCSA. This may explain any apparent lack
of insight into the psyche of computer scientists. At least he hasn't resorted
to childish personal insults. I'll bet he knows how to spell "scruples", to
boot.
Now, what's your excuse?
Darryl Wagoner
: In article <3e1pqm$7...@news.halcyon.com>, Brett Kappenman <br...@halcyon.com> writes:
: It's equivalent to giving out your CC number over a phone line that
: you suspect may be tapped by thousands of different people.
THOUSANDS!! Hardly! Maybe a dozen at any given time and most of those
are key people. It isn't likely that those folks are going to be snatching
CC. It is still possible but I think the risk is really over blown!
It isn't anywhere near as risky as given out our CC on a cell phone.
I do agree that we need a secure way to transmit CC over the net, but
I am not going to lose any sleep over sending mine over the net until
a secure means is found.
--
Darryl Wagoner dar...@sai.com http://www.sai.com/
Office: 603.672.0736 Fax: 603-672-4846
Darryl Wagoner
: In article <3e81p1$j...@nic.scruz.net>, c...@webcom.com (Chris Schefler) writes:
: It's not necessary to electronically sniff the backbone. Any machine
: on the net can be configured as a packet sniffer to capture any
: and all packets flowing through the segment of the net that the
: particular machine resides on.
Yes it necessary!!!!!!!!! Sure you can sniffer on your own ethernet
segment. Big deal! For a sniffer to catch CC then you would have to
filter on many possible internet malls to catch a very few cards. Not
worth while. You would make more money working at Burger King.
The only segment that it would be effective is on the mall's segment.
The rest isn't ethernet and a Unix based sniffer is useless.
Remco Treffkorn
: >the probability that *I* will be a victim?
: It's quite probable, really. Most people with the IQ and the equipment
: *will* do it, just for the sake of doing it. You must not understand
: computer scientists very well. Most computer scientists will do anything,
: just to see if it can be done. There are probably a few that would sell
: it (I probably would). And like everything else, it would fall into the
: wrong hands and the criminals would end up with it. Then you're a victim.
With all due respect sir, you are an idiot. Since I am a computer sientist,
does that mean that I do not know myself very well, and that I should seek
treatment? You are very amusing.
In the last twenty years I learned alot about security holes that could
be used to make a fast buck, but I did not do that. Why? I like my job.
I like my freedom. I don't like beeing only with cell mates.
In short: I have something to loose, and lack the criminal energy to
do something. OTOH, if an opportunity came along so that I could be
sure that I would not get caught and the amount is big enuff, I *might*
be tempted. But I probably would not do anything anyway. Maybe I am just
naive to assume that most educated people are inherently honest.
The best preventer of crime is people with scrouples. If you are so smart
to find a sure fire way to cheat some people out of their money, why sell
the idea? Why not doing it yourself? Scared of going to jail?
The guy you sell the idea to must be even stupider than you are, else he
would not take the risk. Since he is so stupid, he will get caught. He will
spill his guts to the DA, just to get is sentence reduced. You will
occupy the cell next to his.
Grow up and get a life!
Remco
James HG Redekop
>: It's not necessary to electronically sniff the backbone. Any machine
>: on the net can be configured as a packet sniffer to capture any
>: and all packets flowing through the segment of the net that the
>: particular machine resides on.
>Yes it necessary!!!!!!!!! Sure you can sniffer on your own ethernet
>segment. Big deal! For a sniffer to catch CC then you would have to
>filter on many possible internet malls to catch a very few cards. Not
>worth while. You would make more money working at Burger King.
>The only segment that it would be effective is on the mall's segment.
>The rest isn't ethernet and a Unix based sniffer is useless.
So you break into a mall's machine, set up a sniffer, and watch orders come
in. It's not hard. Y'get a few numbers, there you go. I'd be surprised if
it hasn't been done. It certainly happens enough with passwords and other
information. An email-order site would be a *perfect* place to set up. Not
only would the CC density in the traffic be higher than on the backbone, but
a lot of these "Let's make money fast on this Internet thing" sites probably
don't really worry too much about security. If people at major computing
centers can't get their stuff secure, why expect small services to?
Doug Taylor
Each time you make a purchase of any kind with your credit card, your
card number, complete with expirey date, is recorded on a little
slip of paper and shoved into a cash register. At the end of the day
someone counts all these slips and sends them onto the companies
accouning dept.
Someone in the accounting dept. rechecks these slips, and then sends
them off to the bank. At the bank someone counts these again and then
sends them off to the credit card company for processing, etc.
Anywhere along this line any store clerk, accounting clerk, bank clerk,
or courier, can easily jot down as many credit card numbers and expiry
dates they may want and presto: they can do what they need to do with
whatever services accept credit card numbers over the phone.
So I ask myself: Why is everyone suddenly so concerned about credit
card security over the internet? As if no has ever laid hands on their
credit card numbers before?
Am I alone in my bafflement?
Doug.
Paul Prescod
Remco Treffkorn <re...@myhost.subdomain.domain> wrote:
>
>With all due respect sir, you are an idiot.
With all due respect, sir, you are rather rude.
>In short: I have something to loose, and lack the criminal energy to
>do something. OTOH, if an opportunity came along so that I could be
>sure that I would not get caught and the amount is big enuff, I *might*
>be tempted.
Is the amount of money in 100 credit cards a "big enuff" amount? What if
you didn't have to do the "collecting" yourself, just sell the list to some
mobster?
>But I probably would not do anything anyway. Maybe I am just
>naive to assume that most educated people are inherently honest.
You are most naive. Intelligence and ethics are mostly unrelated. Many
educated people did things we would consider despicable in WW2.
>The best preventer of crime is people with scrouples. If you are so smart
>to find a sure fire way to cheat some people out of their money, why sell
>the idea? Why not doing it yourself? Scared of going to jail?
Exactly. There is no flaw in his logic. He is looking for the greatest
profit with the least risk. There is a ton of profit in capturing credit
card numbers.
I would suggest that the best way to pay for something online is to hang up
the phone, call a third party that is NOT Internet connected and do the
transaction through them.
Paul Prescod
Remco Treffkorn
Organization: String to put in the Organization Header
Distribution:
Jon Tara (jt...@cts.com) wrote:
: of insight into the psyche of computer scientists. At least he hasn't
: resorted
: to childish personal insults. I'll bet he knows how to spell "scruples", to
: boot.
: Now, what's your excuse?
Simply beeing a german national. How many languages are you fluent in?
Now you look like a fool, and you deserve it.
The simple point is: This thread is dead, it almost was dead from day
one. You are obviously happy to know that people have an excuse for
wasting bandwidth. I'd much rather have 'em stop.
BTW: I fail to find 'childish personal insults' in my post. If you are
willing to elaborate, please do it by e-mail.
Re...@emc.rvt.com
Remco.
Ed Thomson
>FWIW, the person you're flaming has, literally, yet to grow up. He's still in
>high school and works part time for NCSA. This may explain any apparent lack
>of insight into the psyche of computer scientists. At least he hasn't resorted
>to childish personal insults. I'll bet he knows how to spell "scruples", to
>boot.
Actually, in all my "idiotness", I can still comprehend the thread idea
of organizing messages. And, being an idiot, I do make sure I know what the
flamee's talking about before I flame.
I guess being "polite" doesn't come with age.
>Now, what's your excuse?
Perhaps, with all due respect, he's the idiot.
Lloyd Zusman
> So I ask myself: Why is everyone suddenly so concerned about credit
> card security over the internet? As if no has ever laid hands on their
> credit card numbers before?
It's because of the "scale" of the problem. There are a small, finite
number of people who have access to your CC number by looking at the
slips of paper, etc. On the net, there's a potentially much greater
number of people who can get a hold of the numbers, because of packet
snooping within the domain of the CC recipient's site, etc.
It's kind of like having all the phones in your small town or large
neighborhood being tappable by any number of people who have a certain
level of technological knowledge, and without your knowing who it may
be. Yes, this isn't qualitatively different from a few people at the
places you do business having access to credit card slips ... but
quantitatively, there is just more of a chance for someone being able
to get your CC number.
It's probably more on the magnitude of people with radio receivers
being able to evesdrop on cellular phone converations and being able
to detect the identification codes of the phones that are in use.
Paul Prescod
Doug Taylor <dta...@interlink.net> wrote:
>So I ask myself: Why is everyone suddenly so concerned about credit
>card security over the internet? As if no has ever laid hands on their
>credit card numbers before?
>
>Am I alone in my bafflement?
There are a couple of reasons:
If everyone who gets ripped off has recently ordered something from,
say Gateway, then we have an easily traceable pattern that will allow
us to nail the guy. Furthermore, if the cards are used in Texas, then
we have yet another clue, (I think Gateway is in Texas).
But if you grab a few credit card numbers from a company you are not
associated with, just by hacking into their systems, and use the cards
in a different country, then we don't have a clue either who you are or
which company has the security leak.
Plus, if you can find a hole in a widely used piece of software (like, say,
AIX and Linux), then you can steal credit cards ALL OVER THE WORLD from
different companies, and are again virtually untraceable.
The best solution is to give your credit card number only to a computer that
is NOT INTERNET CONNECTED. As long as they are internet connected, you have
to trust the competence of the sysadmin. By dialing an unconnected third
company you reduce (but do not eliminate) the risk.
At the very least you should only give your card number to a respected
third party, not to the actual company you are buying from. Who knows
how competent their sysadmin is?
Paul Prescod
Ed Thomson
>: It's quite probable, really. Most people with the IQ and the equipment
>: *will* do it, just for the sake of doing it. You must not understand
>: computer scientists very well. Most computer scientists will do anything,
>: just to see if it can be done. There are probably a few that would sell
>: it (I probably would). And like everything else, it would fall into the
>: wrong hands and the criminals would end up with it. Then you're a victim.
>With all due respect sir, you are an idiot. Since I am a computer sientist,
>does that mean that I do not know myself very well, and that I should seek
>treatment? You are very amusing.
Uhm...you appearantly misinterpreted -- and perhaps I was too vague.
I was following up to somebody's quote about "Nobody wanting to spend enough
time to break RSA...". You appearantly thought I was following up to
the thought that "any computer scientist would try *something illegal*,
just to see if it could be done", whereas I meant "any computer scientist
would try *breaking PGP*, just to see if it could be done". It's the
hackers tradition.
>In the last twenty years I learned alot about security holes that could
>be used to make a fast buck, but I did not do that. Why? I like my job.
>I like my freedom. I don't like beeing only with cell mates.
Uhm...did you learn about these things by doing them yourself? Any of them
at all? (Like telnetting to a Unix machine's SMTP port to see if you could
fake mail?) This is exactly what I said in my post ("Most computer scientists
will do anything, just to see if it can be done.")
>The guy you sell the idea to must be even stupider than you are, else he
>would not take the risk. Since he is so stupid, he will get caught. He will
>spill his guts to the DA, just to get is sentence reduced. You will
>occupy the cell next to his.
>Grow up and get a life!
Maybe before you flame, you ought to make sure you understand what the
Darryl Wagoner
: So you break into a mall's machine, set up a sniffer, and watch orders come
: in. It's not hard. Y'get a few numbers, there you go. I'd be surprised if
: it hasn't been done. It certainly happens enough with passwords and other
: information. An email-order site would be a *perfect* place to set up. Not
: only would the CC density in the traffic be higher than on the backbone, but
: a lot of these "Let's make money fast on this Internet thing" sites probably
: don't really worry too much about security. If people at major computing
: centers can't get their stuff secure, why expect small services to?
This is a good point. If security is lacks on the mall net then
it is easy pickings. Of course if you can break into a mall's system then
why worry about a sniffer. Just ftp the customer database easy and less
risk. I don't expect the customer database to be encrypted.
But as I say! THIS IS A VERY GOOD POINT! Anyone running a mall best
have their security act together, because the hack attack is coming.
-darryl
Wolf Paul
|> So you break into a mall's machine, set up a sniffer, and watch orders come
|> in. It's not hard. Y'get a few numbers, there you go. I'd be surprised if
|> it hasn't been done. It certainly happens enough with passwords and other
|> information. An email-order site would be a *perfect* place to set up. Not
|> only would the CC density in the traffic be higher than on the backbone, but
|> a lot of these "Let's make money fast on this Internet thing" sites probably
|> don't really worry too much about security. If people at major computing
|> centers can't get their stuff secure, why expect small services to?
At that point you should not use credit cards to buy anything from a vendor who
has an internet presence. Chances are that the computer their sales people enter
your securely transmitted (snail mail, fax, telephone) card number into for billing
purposes is on the same LAN as their internet-connected machine, and if so, any
hacker worth his salt would have no trouble at all getting at your credit card.
So, just go and toss your cards. You're better of without them.
--
V Wolf N. Paul, UNIX Support/KSR w...@aut.alcatel.at
+-----------------+ Alcatel Austria AG +43-1-277-22-2523 (w)
| A L C A T E L | Scheydgasse 41/E26 +43-1-277-22-118 (fax)
+-----------------+ A-1210 Vienna, Austria (Europe) +43-1-220-6481 (h)
James HG Redekop
>James HG Redekop (tz...@csd.uwo.ca) wrote:
>
>: So you break into a mall's machine, set up a sniffer, and watch orders come
>: in. It's not hard. Y'get a few numbers, there you go. I'd be surprised if
>: it hasn't been done. It certainly happens enough with passwords and other
>: information. An email-order site would be a *perfect* place to set up. Not
>: only would the CC density in the traffic be higher than on the backbone, but
>: a lot of these "Let's make money fast on this Internet thing" sites probably
>: don't really worry too much about security. If people at major computing
>: centers can't get their stuff secure, why expect small services to?
>
>This is a good point. If security is lacks on the mall net then
>it is easy pickings. Of course if you can break into a mall's system then
>why worry about a sniffer. Just ftp the customer database easy and less
>risk. I don't expect the customer database to be encrypted.
Just based on my casual observations of life at a major net site, I would
expect security on the customer database to be better than that on the net
connection.
UWO is pretty good about security, thanks in part to my SO's efforts, but
break-ins still happen about once a year due to poor passwords, new UNIX
holes, etc. But they do keep important files protected.
Then again, there are plenty of clueless sites out there, too.
>But as I say! THIS IS A VERY GOOD POINT! Anyone running a mall best
>have their security act together, because the hack attack is coming.
Oh, I expect it's started already. The basic rule is, if you've thought of
a scenario a hacker might try out, chances are that there's a hacker who's
thought of it already.
kw...@gkar.phys.unm.edu
Lloyd Zusman <l...@panix.com> wrote:
>In article <3ef0hv$i...@ns.RezoNet.NET>, Doug Taylor <dta...@interlink.net>
writes:
>
>> So I ask myself: Why is everyone suddenly so concerned about credit
>> card security over the internet? As if no has ever laid hands on their
>> credit card numbers before?
>
>It's because of the "scale" of the problem. There are a small, finite
>number of people who have access to your CC number by looking at the
>slips of paper, etc. On the net, there's a potentially much greater
>number of people who can get a hold of the numbers, because of packet
>snooping within the domain of the CC recipient's site, etc.
>
There also are programs set up at the credit card companies to hunt
for this kind of abuse via patterns in invalid charges, etc.
When you can limit the number of suspects in an ongoing fraud to
the employees of one or a few local processing, or merchant companies,
it is much easier to trace than in the case of the net, where not only
do you have to suspect anyone with access to the net domain, but you
also have to determine first that it is not one of the more traditional
types of card number grabbing.
Kyle L. Webb Dept. of Physics + Astronomy
kw...@carina.unm.edu University of New Mexico
D. Linford
Doug Taylor <dta...@interlink.net> wrote:
>Each time you make a purchase of any kind with your credit card, your
>card number, complete with expirey date, is recorded on a little
>Anywhere along this line any store clerk, accounting clerk, bank clerk,
>or courier, can easily jot down as many credit card numbers and expiry
>dates they may want and presto: they can do what they need to do with
>whatever services accept credit card numbers over the phone.
>
>So I ask myself: Why is everyone suddenly so concerned about credit
>card security over the internet? As if no has ever laid hands on their
>credit card numbers before?
The worthwhile credit card scams require lots of numbers, and
have a limited time to complete. In electronic form, this is much
easier to pull off...
d
--
---- D.Linford ----- Van.BC ----
---- dlin...@helix.net --------
Phillip J. Windley
This is a good point. If security is lacks on the mall net then
it is easy pickings. Of course if you can break into a mall's system then
why worry about a sniffer.
This brings up the most important point on this whole debate. There's a
lot of concern by potential customers of netsites about having their credit
card sniffed on the net. If your the customer, your liability is limited
to $50 and most CC companies won't even make you pay that (I know from
experience and no, my card number wasn't stolen on the net, but by some kid
in a store). The companies taking CC nos. over the net are the ones at
risk because the bank will take the money out of the merchant's account and
ask questions later.
So, if you're a customer, fire away; don't worry. If your the netstore, be
careful.
Just ftp the customer database easy and less
risk. I don't expect the customer database to be encrypted.
Why? its not hard to do with PGP (or the commercial equivalent). Encrypt
orders with a pbulic key as they come in and only decrypt them offline on a
machine not reachable from the net. Easy to do and effective.
Anyone storing large numbers of unencrypted CC Nos. on the net is foolish.
But as I say! THIS IS A VERY GOOD POINT! Anyone running a mall best
have their security act together, because the hack attack is coming.
Yes they should. And most sysadmin's don't know enough about security to
do a good job. Hire a consultant.
--
__________________________________________________________________________
Phillip J. Windley, Asst. Professor | win...@cs.byu.edu
Laboratory for Applied Logic |
Dept. of Computer Science, TMCB 3370 |
Brigham Young University | Phone: 801.378.3722
Provo UT 84602-6576 | Fax: 801.378.7775
------------------------------------------------------------------------
If you use WWW, I can be found <A
HREF="http://lal.cs.byu.edu/people/windley/windley.html">here</A> or<A
HREF="http://www.imall.com/homepage.html">here</A>.
Phillip J. Windley
In article <D1x00...@undergrad.math.uwaterloo.ca> papr...@undergrad.math.uwaterloo.ca (Paul Prescod) writes:
The best solution is to give your credit card number only to a computer that
is NOT INTERNET CONNECTED. As long as they are internet connected, you have
to trust the competence of the sysadmin. By dialing an unconnected third
company you reduce (but do not eliminate) the risk.
At the very least you should only give your card number to a respected
third party, not to the actual company you are buying from.
Why are you worried? Even if your card gets ripped off, you're not at risk.
Your liability is limited by law and most banks won't make you pay a cent.
I've been there. Its a hassle to get new cards, but not that big and the
likelyhood its going to happen to you is small.
Who knows
how competent their sysadmin is?
Again, as a customer you don't have to worry. The banks might be worried
though. Perhaps they could set up some sort of certification program (for
a company, not the sysadmin)? Just a thought.
James HG Redekop
Phillip J. Windley <win...@cs.byu.edu> wrote:
>Why are you worried? Even if your card gets ripped off, you're not at risk.
>Your liability is limited by law and most banks won't make you pay a cent.
>I've been there. Its a hassle to get new cards, but not that big and the
>likelyhood its going to happen to you is small.
And the store or bank looses money through the fraud, and, in order to recoup
the losses, raises prices or rates -- that you have to pay.
Just because the theft doesn't hit your bank account directly doesn't mean you
shouldn't be concerned about it.
Kaitlin Duck Sherwood
> Uhm...did you learn about these things by doing them yourself? Any of them
> at all? (Like telnetting to a Unix machine's SMTP port to see if you could
> fake mail?) This is exactly what I said in my post ("Most computer scientists
> will do anything, just to see if it can be done.")
I have done all kinds of rude, technically immoral things to find
out if they could be done - because I needed to know for my job.
For example, I worked on an email <-> WWW gateway, so it was
imperative that I learn how to spoof email. I have learned how
to spoof usenet articles for the same reason. *However* I have never
ever ever used this knowledge for personal gain or to damage another
person. (I also was very careful that Casual User couldn't
use what I had learned to spoof him/herself, an effort Netscape
made irrelevant, but that's a different thread.)
Many computer scientists are curious types. This curiosity does not
however translate into maliciousness. In fact, in Bruce Sterling's
_The Hacker Crackdown_ (a good read, available in its entirety at
http://ice-www.larc.nasa.gov/ICE/papers/hacker-crackdown.html ),
the author was amazed at how exceedingly *rare* hacking for personal
gain was.
I know a programmer who photocopied a dollar bill and fed it into a
Coke machine "to see if it could be done". (It could.) However,
once he satisfied his curiousity, he never did it again.
I personally feel that Jane Computer Programmer is a much lower risk
than Joe Gap Clerk.
Paul Phillips
>Anyone storing large numbers of unencrypted CC Nos. on the net is foolish.
Anyone storing any number of unencrypted credit card numbers anywhere
is very foolish. Including on local machines with an air gap. Furrfu,
this is very basic stuff.
-PSP
--
"Listen up, Wolff: I don't want to hear a single fucking word from a snake-oil
huckster like you about "free speech" until you've demonstrated that you've
figured out not to send unsolicited electronic mail advertising your miserable
products." -- Tim Pierce, alt.internet.media-coverage
Ed Thomson
[snip]
>Many computer scientists are curious types. This curiosity does not
>however translate into maliciousness.
[snip]
>I know a programmer who photocopied a dollar bill and fed it into a
>Coke machine "to see if it could be done". (It could.) However,
>once he satisfied his curiousity, he never did it again.
[snip]
>I personally feel that Jane Computer Programmer is a much lower risk
>than Joe Gap Clerk.
Thank you -- this is exactly the point that I was trying to make. The spin-off
of the original thread that I replied to was debating whether or not RSA could
be cracked or not. As long as there are curious computer scientists, anything
can get done with computers.
Mark Stout
>>I know a programmer who photocopied a dollar bill and fed it into a
>>Coke machine "to see if it could be done". (It could.) However,
>>once he satisfied his curiousity, he never did it again.
>[snip]
>>I personally feel that Jane Computer Programmer is a much lower risk
>>than Joe Gap Clerk.
>
>Thank you -- this is exactly the point that I was trying to make. The spin-off
I have to agree. But back to the subject of transmitting CC#s over the Internet,
wouldn't it be just as simple as sending your public key, only encrypted? Do the
same thing with your CC# as you do your Name. Instead of a phone number
and your name, it's your CC# and your name. Only the secure key would be
needed to decrypt it at the other end. A siple mail message would transport once
and that store would have it available for future purchases. ALl these would be
keep offline in a database for future refernce and safegaurding with a connection
to the database tables for lookup functions. Seems to me in you encrypted it so
no one could read it without your secure key, you're safe. Am I missing something?
Ciao,
Mark
=======================================================================
Mark Stout | mcs...@netcom.com/mark_...@ccm.fm.intel.com
| Certified Netware Engineer, LAN Analysis
Disclaimer | My opinions are just that, Mine, not my employer's
-------------+---------------------------------------------------------
Published WWW Pages:ftp://ftp.netcom.com/pub/mc/mcstout/www/index.html
Finger for Public Key
-----------------------------------------------------------------------
WINTER is Nature's way of saying, "UP YOUR'S!"
=======================================================================