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