1996-02-06 - Re: FV’s blatant double standards

Header Data

From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: jpp@software.net>
Message Hash: 81a5d89cba4d5edad6bb5c0b6c40638e0406a4f86f635de5da41c1c628a53637
Message ID: <cl5nmoeMc50eIYnJg9@nsb.fv.com>
Reply To: <2.2.32.19960205213944.0109c138@mail.software.net>
UTC Datetime: 1996-02-06 11:50:47 UTC
Raw Date: Tue, 6 Feb 1996 19:50:47 +0800

Raw message

From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Tue, 6 Feb 1996 19:50:47 +0800
To: jpp@software.net>
Subject: Re: FV's blatant double standards
In-Reply-To: <2.2.32.19960205213944.0109c138@mail.software.net>
Message-ID: <cl5nmoeMc50eIYnJg9@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain


I've debunked this one before, but let me say it again.  John outlines
essentially the same scheme for an automated attack on FV that was
previously posted by Jeff Weinstein at Netscape.  (Actually, to be fair,
Jeff's was considerably more sophsticated in its attempt to avoid
detection by FV.)  John's approach will essentially change all negative
FV confirmation answers to positive ones.  There are a couple of key
flaws in his approach:

1.  He doesn't explain how he's going to spot the VirtualPIN in the
outgoing stream.  Given the non-structured nature of the VirtualPIN,
this alone probably requires more sophistication than our entire attack
program.

2.  He acknowledges that this approach will miss anyone who isn't buying
things from the machine that actually composes his mail messages.  What
he doesn't seem to realize, however, is that this means that any
automated attack will cause "fraud" to be called as soon as it hits a
user of AOL, Compuserve, etc.  Jeff's approach would last a bit longer,
but is also vulnerable to heterogeneous mail environments.  The real
point is that an automated attack like this one is undermined by email
heterogeneity, which will cause FV's fraud department to be alerted
quite quickly & trace things down.  In contrast, the attack we've
outlined on credit card numbers is simple, single-step, and has no
obvious "misfiring path" that would lead to quick detection.  It could
do its dirty work for a long time.  

Simson's comment almost, but not quite, made this clear:

> Yes, clearly if you are not concerned about missing 50-75% of First Virtual's 
> users, this attack will work just fine.

The "just fine" is incorrect, however, because those 50-75% will not be
MISSED, they will be attacked incompletely, and they will object to
false transactions, causing our fraud department to launch an
investigation.  This attack would get stopped pretty quickly, I believe.
 -- Nathaniel
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com





Thread