From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Jeff Weinstein <jsw@netscape.com>
Message Hash: 79896ebcb0df6dd7cee0e6acb34d55e3bd49a6b5a611abb7db037977133b158d
Message ID: <Il4wSxCMc50eB5gVAo@nsb.fv.com>
Reply To: <01BAEF34.AA95ECC0@ploshin.tiac.net>
UTC Datetime: 1996-02-03 20:57:06 UTC
Raw Date: Sun, 4 Feb 1996 04:57:06 +0800
From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Sun, 4 Feb 1996 04:57:06 +0800
To: Jeff Weinstein <jsw@netscape.com>
Subject: Re: Flaw in Netscape rejoinder (was Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards)
In-Reply-To: <01BAEF34.AA95ECC0@ploshin.tiac.net>
Message-ID: <Il4wSxCMc50eB5gVAo@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain
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
Return to February 1996
Return to “Tony Iannotti <tony@secapl.com>”