At 09:53 AM 1/30/96 -0500, Nathaniel Borenstein wrote:
As to how the credit card numbers are entered: they are entered at account setup time via a telephone call.
Then why should an attacker even bother to infect users' machines with your program? There is a much better way. Let me outline it for you: The keyboard sniffer can be modified to attach to the computer which holds your customer database. It simply watches for card numbers (which is even more trivial than doing so on the client's machine, as it's the only thing this machine does) and stores them. Then, when the attacker calls in to set up an account, the keyboard sniffer is alerted (by any of several methods, such as a specific, probably invalid, credit card number) and replaces this value with a card number that was previously captured. In this manner the attacker has obtained a valid FV account drawn on a valid credit card number of a real FV customer. This account can then be used to purchase various goods and services. And while it causes a similar degree of damage as your previous scheme, it also causes you to lose money in the process. Since you are the verifier (in the function of the bank) in this case, then you will lose out in the event of fraud. The credit card companies will still receive their money, and guess who will pay it: FV! This method has several other benefits over your previous scheme. Your scheme required infection of numerous computers; this scheme requires infecting only one computer. And while one may be held liable for the infection of the database computer, the person who opens the fake FV account cannot. All s/he has done is call you up and follow procedure. Even if he were dumb enough (as we know many criminals are) to give you his real card number over the telephone, it would not show up in your database. He would be completely clean... no trace. Furthermore, once the rogue program is in place, EVERY attack succeeds. As a corollary to this attack, the attacker could design his/her trojan to watch for the creation of new accounts and replace the intended FV_ID with another value created by a PRNG seeded by a known value. The attacker can then seed his/her copy of the PRNG with the same value and conduct valid (although fraudulent) transactions using the generated FV_IDs. With this approach he does not even have to contact your new accounts office via telephone; s/he simply implants the trojan and begins making transactions. This is similar to the above attack with regard to payment liability. --- Jeremy Mineweaser | GCS/E d->-- s:- a--- C++(+++)$ ULC++(++++)>$ P+>++$ j.mineweaser@ieee.org | L+>++ E-(---) W++ N+ !o-- K+>++ w+(++++) O- M-- | V-(--) PS+(--) PE++ Y++>$ PGP++>+++$ t+() 5 X+ R+() *ai*vr*vx*crypto* | tv(+) b++>+++ DI+(++) D+ G++ e>+++ h-() r-@ !y-