RE: No FV supporters?

Nathaniel seems to be defending his cause sufficiently well, 
and graciously answering the abuse.  Some of the abusers 
are showing a fairly comprehensive lack of knowledge of the 
FV system.

I would venture to say that FV has no more profit motivation
than, say, Netscape--or how about Open Market?  They who
gleefully opened a "Here are the secure servers that haven't 
been hacked" page some time ago.  That was pretty self-
serving, wasn't it?

Nor would I consider the FV brouhaha much more obvious
than, say, the front page announcements about "NFS and 
RPC considered dangerous" that hit the big papers last year.
The weaknesses of those protocols for internetworking have
long been known to those working with TCP/IP.

Now, clearly there are lots of opinions on FV's system, but
if people like Sameer and Rich Salz (e.g., who have reputations
as knowledgeable and aware) are going to trash FV it
would mean a lot more to many readers if they could state
more specifically what it is about FV that doesn't work (or that
doesn't work as well as, say, SSL or CyberCash or Open 
Market's approaches).

As for the Weld Pond/et al graphical clicking approaches,
they may work and they may defend against some attacks, 
but I won't use it (too much clicking around, too likely to 
make mistakes) and neither will anyone without a GUI.

My $0.02.

-Pete Loshin
 pete@loshin.com

Ted Anderson wrote:

>I am rather shocked that after wading through hundreds of msgs of abuse
>of Nathaniel and FV I haven't seen one message of support; but perhaps I
>missed it.

etc.

Excerpts from mail.cypherpunks: 1-Feb-96 Re: Flaw in Netscape rejoin..
Jeff Weinstein@netscape. (10884*)

>   You would not send the FV ID to the "bad guys" until you saw a complete
> FV transaction take place.  You remember the ID when you see it, but
> only send it after seeing the e-mail verification message.

But there's no obvious correlation between the VirtualPIN as it appears
in the web transaction and the message that comes back!  In other words,
what you might be sniffing for in the web page would be a form that said
"Enter your Virtual PIN here".  But what comes back will be a mail
message that does NOT include the Virtual PIN and in which there's no
way that I can think of to do the correlation.  (That's a design
feature.)  This means that your algorithm will trigger if the host
machine gets ANY transfer-query back from FV, but it might not be
associated with the VirtualPIN that you previously intercepted.  The
correlation at this stage is VERY hard, and when you misfire, our fraud
department gets a quick heads up.

>   It should be quite easy to determine what protocol a user uses to read
> their mail from within winsock.  If we want to limit it to pop3 users, we
> could just keep track of connections to port 110.  As noted before, if
> they don't use pop we don't target them.

But you don't know, when you intercept a Virtual PIN, whether you've
intercepted the one that belongs to the user whose machine you've
infected.  This scheme will break down very quickly in "promiscuous"
environments like universities, CyberCafes, etc.  How will your attack
program know not to make the wrong decision in any environment where
more than a single user ever uses the machine?

The point is that if it misfires with any frequency at all -- even 1% of
the time -- we'll get some quick heads up about the ongoing fraud.

>   With the explosive growth of internet connected PCs, I think that
> the number of people who "surf" and read e-mail on different machines
> is dwindling rapidly.  I am happy to skip those old guard of the
> internet and concentrate on the newbies who only have one computer
> and one account.

Yes, I certainly understand that this is Netscape's product strategy,
and I think it is a VERY GOOD ONE at the level of selling tools to
users, which you guys are clearly great at.  However, the Internet
really is very heterogeneous, and is likely to continue to be so. 
Trends like CyberCafes are likely to make there continue to be a large
number of non-personal machines for a long time to come.  And unless
your attack program can figure out how NOT to infect such machines, it's
going to tip its hand fairly fast, especially since such machines will
probably be among the MOST vulnerable to various kinds of automated
infection.

>   I still think that someone could construct an attack against the
> current FV system using the techniques I've described.  It would be
> more complicated to construct than the keyboard attack but that has
> been proven time and again not to be a barrier.  Someone who could
> construct the Morris worm or the year ago IP spoofing attacks could
> do it. 

I think we're already way beyond that in complexity, and you still
haven't outlined all the necessary pieces of a successful automated
attack.  But even if you are eventually successful in devising an
automated attack on FV, it's already clear that it's going to be far,
far more complicated than the attack we've outlined on
software-encrypted credit card numbers.  If you take seriously the
notion that an automated attack should be as hard as possible, I think
the advantages of our system are already crystal clear.

>   I think that you may have to rethink some of your assumptions that
> were valid back when you designed the system, but are no longer given
> the current growth and changing demographics of the internet.

I like CyberCafes.  I like public access terminals in airports and
universities.  I like programs that create "terminal rooms" in the inner
cities to allow disadvantaged people to access the net.  All of these
are part of the current growth and changing demographics of the
Internet, too.

I do agree with you that if the Internet becomes much more homogeneous,
an automated attack on FV will become easier.  EVERYTHING becomes more
vulnerable in a homogeneous world, as in an ecosystem.  Diversity helps
to protect the health of the overall ecology.  Fortunately, I don't see
extreme homogeneity coming to the Internet any time soon.  Major
platforms from Microsoft and Netscape, for example, might well attain
80% market dominance, but the remaining 20% has a vital role to play in
keeping the net healthy.  Helping to thwart a complex automated attack
is just one example of this more general observation.

>   I'd really like to see some effort spent on closing some of the more
> gaping holes in the underlying systems.  Why should it be so easy
> for one program to snoop on the keystrokes directed to another?
> Why should it be so easy for a program downloaded from the net
> to patch a part of the operating system?

Agreed completely.  On the other hand, trends from OS vendors seem to be
moving in quite the opposite direction.  Think about "click here to
execute" in mail or news postings on the Microsoft Network.  And someone
recently told me (don't know if it's true) that Microsoft's OCX
architecture for executable web content is the best avenue yet for
creating Trojan Horses......  And I, for one, am deeply uneasy about
Java's security model, too.  -- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com

I'm way behind on my email, but someone suggested privately that I
should respond to Jeff's mail, so I've bumped it to the top of the queue:

Excerpts from mail.cypherpunks: 30-Jan-96 Re: No FV supporters? Jeff
Weinstein@netscape. (903*)

> I sent a description of an attack against FV based on replacing
> or hacking winsock to cypherpunks last night.  This attack seems
> to meet Borenstein's criteria of being as automated and implementable
> on a mass scale as their keyboard snooping attack.  So far I have not
> seen any response from FV.

Sorry for the delay.  I don't think your attack against FV works
anywhere nearly as well as our attack against software-encrypted credit
card numbers, as I'll explain below.

I should also apologize for the fact that I couldn't resist in pointing
out lots of little problems with your proposed attack, and that I'm
responding to your plan in the order you described it.  This means that
we don't get to the really major flaw in your strategy towards the end,
so what comes at first will seem like nitpicking.

Excerpts from mail.cypherpunks: 30-Jan-96 Re: FV Demonstrates Fatal F..
Jeff Weinstein@netscape. (2739*)

> It would not be much harder than the demonstrated keyboard attack
> to create a hacked version of winsock that would implement an
> attack against First Virtual.  If the attacker had a list of web
> pages that accept FV payments it would be very easy to collect
> the ID numbers.  

A list of stores?  First of all, this attack is already amazingly
focused.  Our DLL to implement the attack on credit cards is 16K, and
doesn't need to target any specific buyers, sellers, or programs.  The
more complex the attack & the bigger the software, the more likely it is
to be noticed.  But this is just a minor nit.  Read on.

> There is no need to attack the large datastream
> of keyboard input when the search can be easily narrowed.  Since
> FV doesn't use encryption the attack could easily be implemented
> in winsock, making it independent of any client software.  

What's really funny (to me, at least) here and in a lot of other aspects
of the cypherpunk reaction to FV is the continuing assumption that the
choice of FV vs encryption is an either/or thing.  Combine FV's Virtual
PIN mechanism with transport encryption and you've indiputably got
something that's a LOT safer than just using credit cards with
encryption, and a bit safer than our current system, too.  But I know,
the correct focus here is FV's current system.  So read on.

At this point in your attack, you skip a step:  You don't explain how
you correlate the FV ID to email address.  This means that your attack
will ONLY work for systems where the user is always using the same PC to
web browse and read his mail.  In practice, even if this is true 99% of
the time, the remaining 1% would probably cause your attack to be
detected pretty quickly if deployed on a large, automated scale.  But,
for the sake of argument, let's imagine that it's true 100% of the time.
 Read on.

> A version
> that infected the win95 IP stack could be quite effective.  The list
> of FV accepting sites would be easily obtainable via a query of
> altavista.  Since the infected system is on the internet and has
> to periodically send its results to the attacker, it could download
> an updated list of FV pages at the same time.  

Seems to me your "not much harder" claim is starting to break down here,
with an automated virus spreading itself all over the net and
downloading lists from altavista weekly.  And the amount of net traffic
you're generating may make this attack a lot more quickly detected than
ours.  (In fact, I imagine that if the folks at AltaVista or Lycos noted
thousands of identical searches focused on merchants accepting First
Virtual, they'd probably contact us, more out of concern for their own
load management than anything else.)  But still, read on -- we're
finally coming to the good part.

> Attacking the e-mail verification step of the FV system could also
> be accomplished via a hacked winsock.  A bit of POP3 aware code
> in the winsock could intercept the verification messages and keep
> the e-mail client from ever seeing them.  It could automatically
> generate "Yes" responses for all such messages.

OK, so you're only interested in POP3 mail tools?  That's wonderful, but
there's also systems that use IMAP, systems that use raw SMTP to locally
resident message stores, and many odder things.  There's also people who
get their mail through AOL, Compuserve, Prodigy, etc.  There's people
who live on a PC or Mac, but who read mail on a UNIX system (e.g. many
Delphi and Netcom users).  

You're not going to catch all of them.  Moreover, even if you say
"that's fine, we only need some of them", your attack is now dead in the
water.  Why?  Because you have no way of telling, in your attack virus,
what kind of technology is going to be used to read mail.  This means
that your attack will inevitably, and quickly, hit some people who DO
receive the mail.  Our fraud department will be quickly notified (when
the user answers "fraud" to our query, a human sees it right away) and
we'll be off to the races, collecting clues.  It will be work tracking
it down, but we'll have a good shot in identifying the attack and
producing a program that helps users spot it on their system (the moral
equivalent of an anti-viral program) in less time than it would take you
to even suspect that the attack FV outlined had taken place in the world
of software-encrypted credit cards.

Your attack would be caught by us relatively quickly because our model
is based not on a single fail-safe piece of security software, but on
*process* security.  The overall process is multifaceted, with many
checks and balances.  What if, for example, I go to someone else's
machine and use their web browser to buy something using MY First
Virtual ID?  Your attack will capture my ID and allow you to try to use
it, but the email confirmation will go elsewhere, quite possibly to an
uninfected machine.  When reproduced on a mass scale, this kind of thing
will be noticed pretty fast.  In contrast, credit cards are a one-way
payment mechanism -- the number (and sometimes some other info typed in
close proximity) is basically all you need.  Just steal that without
getting noticed and the crime is done.

>   I believe that FV is just as vulnerable to these types of
> attacks as any of the encryption based credit card schemes, if
> not more so.  The thing that really protects FV is that it can
> only be used to buy bit, not real goods, and the bad guys don't
> generally care about stealing bits.  This is also what makes FV
> not generally useful to people who want to shop over the internet.

Actually, you're a bit behind the times.  We removed that restriction
from our system a couple of months ago.  There still aren't many people
using our system for physical goods, mostly because of our 91-day fund
holding period, but we have gotten the green light from our financial
partners to waive that for qualified, established merchants, once we
make a few technical changes behind the scenes.

The fact is that our original restriction against physical goods was
never designed to protect against fraud.  Rather, it was a conscious
attempt to do two things:  1) bound the risk our bank perceived in being
the first bank ever to explicitly agree to handle an Internet-based
payment system (this was mid-1994, remember), and 2) to focus the
attention of our prospective users on the situations that were in fact
reasonably well-suited to an economic model in which consumers had the
explicit option of refusing payment.  Some of our sellers very quickly
realized that no matter what we said, it was straightforward to use our
system for physical goods, shipping them only after the consumer said
"yes", and we eventually changed our terms and conditions to reflect
that reality.  The 91 day hold, on the other hand, WAS designed to
protect against fraud -- from the *merchant* side, which is why we have
no qualms about waiving it for qualified merchants.

Now, actually, I want to commend you.  This is as close as I've ever
seen anyone come to constructing a plausible automated attack on FV. 
The IP stack is a very clever attack vector, and I honestly can't claim
to have anticipated it.  However, I do think that the flaw in your
approach reinforces my belief in the importance of multi-layered
defenses.  In fact, a multi-layered security strategy is the ONLY
defense against vulnerabilities you haven't thought of yet.  That's the
real reason why ANY scheme based on one-way instruments like credit card
numbers is particularly hard to make secure.  -- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com

On Wed, 31 Jan 1996, Nathaniel Borenstein wrote:

> choice of FV vs encryption is an either/or thing.  Combine FV's Virtual
> PIN mechanism with transport encryption and you've indiputably got
> something that's a LOT safer than just using credit cards with
> encryption, and a bit safer than our current system, too.  But I know,

Belt & Suspenders is Good (and you want the best and best tested of both.)
I may be being naive, but I think the contest profits all, so as brothers 
fight ye! ;-)

Nathaniel Borenstein wrote:
> I should also apologize for the fact that I couldn't resist in pointing
> out lots of little problems with your proposed attack, and that I'm
> responding to your plan in the order you described it.  This means that
> we don't get to the really major flaw in your strategy towards the end,
> so what comes at first will seem like nitpicking.

  No problem.  This is how we find flaws and make systems stronger.

> Excerpts from mail.cypherpunks: 30-Jan-96 Re: FV Demonstrates Fatal F..
> Jeff Weinstein@netscape. (2739*)
> 
> > It would not be much harder than the demonstrated keyboard attack
> > to create a hacked version of winsock that would implement an
> > attack against First Virtual.  If the attacker had a list of web
> > pages that accept FV payments it would be very easy to collect
> > the ID numbers.
> 
> A list of stores?  First of all, this attack is already amazingly
> focused.  Our DLL to implement the attack on credit cards is 16K, and
> doesn't need to target any specific buyers, sellers, or programs.  The
> more complex the attack & the bigger the software, the more likely it is
> to be noticed.  But this is just a minor nit.  Read on.

  A gigabyte drive has lots of corners to hide stuff.  A list of the
top 1000 first virtual sites would not be very large.  On a windows
system it could be hidden in the c:\windows\system directory, where
a 100k file with an unintelligible name would not seem unusual.

> > There is no need to attack the large datastream
> > of keyboard input when the search can be easily narrowed.  Since
> > FV doesn't use encryption the attack could easily be implemented
> > in winsock, making it independent of any client software.
> 
> What's really funny (to me, at least) here and in a lot of other aspects
> of the cypherpunk reaction to FV is the continuing assumption that the
> choice of FV vs encryption is an either/or thing.  Combine FV's Virtual
> PIN mechanism with transport encryption and you've indiputably got
> something that's a LOT safer than just using credit cards with
> encryption, and a bit safer than our current system, too.  But I know,
> the correct focus here is FV's current system.  So read on.
> 
> At this point in your attack, you skip a step:  You don't explain how
> you correlate the FV ID to email address.  This means that your attack
> will ONLY work for systems where the user is always using the same PC to
> web browse and read his mail.  In practice, even if this is true 99% of
> the time, the remaining 1% would probably cause your attack to be
> detected pretty quickly if deployed on a large, automated scale.  But,
> for the sake of argument, let's imagine that it's true 100% of the time.
>  Read on.

  You would not send the FV ID to the "bad guys" until you saw a complete
FV transaction take place.  You remember the ID when you see it, but
only send it after seeing the e-mail verification message.

> > A version
> > that infected the win95 IP stack could be quite effective.  The list
> > of FV accepting sites would be easily obtainable via a query of
> > altavista.  Since the infected system is on the internet and has
> > to periodically send its results to the attacker, it could download
> > an updated list of FV pages at the same time.
> 
> Seems to me your "not much harder" claim is starting to break down here,
> with an automated virus spreading itself all over the net and
> downloading lists from altavista weekly.  And the amount of net traffic
> you're generating may make this attack a lot more quickly detected than
> ours.  (In fact, I imagine that if the folks at AltaVista or Lycos noted
> thousands of identical searches focused on merchants accepting First
> Virtual, they'd probably contact us, more out of concern for their own
> load management than anything else.)  But still, read on -- we're
> finally coming to the good part.

  I guess I didn't explain this well enough.  The attacker would do
a single altavista query, and then broadcast it via some existing
mechanism over the net.  Weekly postings to some low volume junk
newsgroup would do the trick.

> > Attacking the e-mail verification step of the FV system could also
> > be accomplished via a hacked winsock.  A bit of POP3 aware code
> > in the winsock could intercept the verification messages and keep
> > the e-mail client from ever seeing them.  It could automatically
> > generate "Yes" responses for all such messages.
> 
> OK, so you're only interested in POP3 mail tools?  That's wonderful, but
> there's also systems that use IMAP, systems that use raw SMTP to locally
> resident message stores, and many odder things.  There's also people who
> get their mail through AOL, Compuserve, Prodigy, etc.  There's people
> who live on a PC or Mac, but who read mail on a UNIX system (e.g. many
> Delphi and Netcom users).

  So I only get half or a third of the millions of people conducting
commerce over the internet.  If this stuff ever really takes off that
will be plenty.

> You're not going to catch all of them.  Moreover, even if you say
> "that's fine, we only need some of them", your attack is now dead in the
> water.  Why?  Because you have no way of telling, in your attack virus,
> what kind of technology is going to be used to read mail.  This means
> that your attack will inevitably, and quickly, hit some people who DO
> receive the mail.  Our fraud department will be quickly notified (when
> the user answers "fraud" to our query, a human sees it right away) and
> we'll be off to the races, collecting clues.  It will be work tracking
> it down, but we'll have a good shot in identifying the attack and
> producing a program that helps users spot it on their system (the moral
> equivalent of an anti-viral program) in less time than it would take you
> to even suspect that the attack FV outlined had taken place in the world
> of software-encrypted credit cards.

  It should be quite easy to determine what protocol a user uses to read
their mail from within winsock.  If we want to limit it to pop3 users, we
could just keep track of connections to port 110.  As noted before, if
they don't use pop we don't target them.

> Your attack would be caught by us relatively quickly because our model
> is based not on a single fail-safe piece of security software, but on
> *process* security.  The overall process is multifaceted, with many
> checks and balances.  What if, for example, I go to someone else's
> machine and use their web browser to buy something using MY First
> Virtual ID?  Your attack will capture my ID and allow you to try to use
> it, but the email confirmation will go elsewhere, quite possibly to an
> uninfected machine.  When reproduced on a mass scale, this kind of thing
> will be noticed pretty fast.  In contrast, credit cards are a one-way
> payment mechanism -- the number (and sometimes some other info typed in
> close proximity) is basically all you need.  Just steal that without
> getting noticed and the crime is done.

  With the explosive growth of internet connected PCs, I think that
the number of people who "surf" and read e-mail on different machines
is dwindling rapidly.  I am happy to skip those old guard of the
internet and concentrate on the newbies who only have one computer
and one account.

> >   I believe that FV is just as vulnerable to these types of
> > attacks as any of the encryption based credit card schemes, if
> > not more so.  The thing that really protects FV is that it can
> > only be used to buy bit, not real goods, and the bad guys don't
> > generally care about stealing bits.  This is also what makes FV
> > not generally useful to people who want to shop over the internet.
> 
> Actually, you're a bit behind the times.  We removed that restriction
> from our system a couple of months ago.  There still aren't many people
> using our system for physical goods, mostly because of our 91-day fund
> holding period, but we have gotten the green light from our financial
> partners to waive that for qualified, established merchants, once we
> make a few technical changes behind the scenes.
> 
> The fact is that our original restriction against physical goods was
> never designed to protect against fraud.  Rather, it was a conscious
> attempt to do two things:  1) bound the risk our bank perceived in being
> the first bank ever to explicitly agree to handle an Internet-based
> payment system (this was mid-1994, remember), and 2) to focus the
> attention of our prospective users on the situations that were in fact
> reasonably well-suited to an economic model in which consumers had the
> explicit option of refusing payment.  Some of our sellers very quickly
> realized that no matter what we said, it was straightforward to use our
> system for physical goods, shipping them only after the consumer said
> "yes", and we eventually changed our terms and conditions to reflect
> that reality.  The 91 day hold, on the other hand, WAS designed to
> protect against fraud -- from the *merchant* side, which is why we have
> no qualms about waiving it for qualified merchants.

  Well this means that an attack against First Virtual would be more
interesting.

> Now, actually, I want to commend you.  This is as close as I've ever
> seen anyone come to constructing a plausible automated attack on FV.
> The IP stack is a very clever attack vector, and I honestly can't claim
> to have anticipated it.  However, I do think that the flaw in your
> approach reinforces my belief in the importance of multi-layered
> defenses.  In fact, a multi-layered security strategy is the ONLY
> defense against vulnerabilities you haven't thought of yet.  That's the
> real reason why ANY scheme based on one-way instruments like credit card
> numbers is particularly hard to make secure.  -- Nathaniel

  I still think that someone could construct an attack against the
current FV system using the techniques I've described.  It would be
more complicated to construct than the keyboard attack but that has
been proven time and again not to be a barrier.  Someone who could
construct the Morris worm or the year ago IP spoofing attacks could
do it. 

  I think that you may have to rethink some of your assumptions that
were valid back when you designed the system, but are no longer given
the current growth and changing demographics of the internet.

  I'd really like to see some effort spent on closing some of the more
gaping holes in the underlying systems.  Why should it be so easy
for one program to snoop on the keystrokes directed to another?
Why should it be so easy for a program downloaded from the net
to patch a part of the operating system?

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Jeff Weinstein wrote:
>   I think that you may have to rethink some of your assumptions that
> were valid back when you designed the system, but are no longer given
> the current growth and changing demographics of the internet.

This is all getting unnecessarily complicated. As I pointed out
in another post ("FV's blatant double standards") NO SYSTEM FOR
SECURITY IS SAFE when one allows for recipient compromise, i.e. 
privileged access to a recipient's system by a malicious program.

>   I'd really like to see some effort spent on closing some of the more
> gaping holes in the underlying systems.  Why should it be so easy
> for one program to snoop on the keystrokes directed to another?

Easy or difficult is not the point. In DOS it's possible for any program,
in Unix only for those with root access. Security fails when it is
not possible to make a distinctionbetween a program that _should_ 
have access and one that _shouldn't_. Anyone who's tried to teach
novice DOS users what to do when one of those anti-virus TSR tools
complains that something is doing something it shouldn't will know
how hard it is for _users_ to guard themselves.

> Why should it be so easy for a program downloaded from the net
> to patch a part of the operating system?

I would think that most viruses are transmitted by floppy
disk, even now, or by programs _intentionally_ downloaded
and _intended_ to patch the OS (such as a screen blanker). 
The possibility of mass net-based creepy-crawlies has been
remote due to the uniquely multi-platform nature if Internet
protocols; they're Unix-based, but end-users have PCs. Only
metaplatforms such as Java, perlCCI, Telescript could change
this.

Rishab

----------------------------------------------------------------------
The Indian Techonomist - newsletter on India's information industry
http://dxm.org/techonomist/                             rishab@dxm.org
Editor and publisher: Rishab Aiyer Ghosh           rishab@arbornet.org
Vox +91 11 6853410; 3760335;     H 34 C Saket, New Delhi 110017, INDIA

Pete Loshin wrote:
> Now, clearly there are lots of opinions on FV's system, but
> if people like Sameer and Rich Salz (e.g., who have reputations
> as knowledgeable and aware) are going to trash FV it
> would mean a lot more to many readers if they could state
> more specifically what it is about FV that doesn't work (or that
> doesn't work as well as, say, SSL or CyberCash or Open
> Market's approaches).

  I sent a description of an attack against FV based on replacing
or hacking winsock to cypherpunks last night.  This attack seems
to meet Borenstein's criteria of being as automated and implementable
on a mass scale as their keyboard snooping attack.  So far I have not
seen any response from FV.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

>   I sent a description of an attack against FV based on replacing
> or hacking winsock to cypherpunks last night.  This attack seems
> to meet Borenstein's criteria of being as automated and implementable
> on a mass scale as their keyboard snooping attack.  So far I have not
> seen any response from FV.

	Would someone like to implement such a thing? That would be
"the cypherpunk way" of properly debunking FV's claims. I wonder if
Simson would put you on the cover of the SJ Merc for doing it..

-- 
Sameer Parekh					Voice:   510-601-9777x3
Community ConneXion, Inc.			FAX:     510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org/ (or login as "guest")		sameer@c2.org

Excerpts from mail.cypherpunks: 30-Jan-96 Re: No FV supporters?
sameer@c2.org (711*)

> 	Would someone like to implement such a thing? That would be
> "the cypherpunk way" of properly debunking FV's claims.

As I just explained, I don't think it would be nearly as effective as
our attack.  But for the record, I must remind everyone on this list of
an important line that should not be crossed:

Our program *demonstrated* key parts of a comprehensive attack on
software-encrypted credit card numbers, but it most carefully did NOT
implement those parts of that attack which would facilitate the actual
theft and transport of those numbers.  If anyone can similarly design
and demonstrate a comprehensive attack on FV, that's their affair. 
However, if they don't follow our lead in acting responsibly, and
instead choose to unleash their software as a live attack, First Virtual
reserves the right to track them down to the best of its abilities and
prosecute them to the full extent of the law.

That's another important aspect of "process security" or multi-layer
security.   You take the legalities seriously.  -- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com

> instead choose to unleash their software as a live attack, First Virtual
> reserves the right to track them down to the best of its abilities and
> prosecute them to the full extent of the law.

	Ever heard of remailers, Nathaniel?

	That aside, I wasn't proposing a full fledged attack that
someone would actually use to commit fraud, just an attack which
would expose FV for the self-serving FUD-spreaders which they are.

-- 
Sameer Parekh					Voice:   510-601-9777x3
Community ConneXion, Inc.			FAX:     510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org/ (or login as "guest")		sameer@c2.org