Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
Nathaniel Borenstein <nsb@nsb.fv.com> writes:
The attack we've outlined -- and partially demonstrated -- is based on the combination of several known flaws:
-- It's easy to put malicious software on consumer machines -- It's easy to monitor keystrokes -- It's trivial to detect credit card numbers in larger data streams -- It's easy to disseminate small amounts of information tracelessly
But take away the inputting of the credit card number via keystroke and the flaw disappears. How would your program deal with a scheme like this? Programs needing secure entry create a "secure entry field" which is really just an imagemap with the digits (and alphas if required) placed randomly about. The user then uses the mouse to click on these numerals. Ideally the graphics that represent the numerals would be drawn from a random pool and are misformed to thwart any OCR attempts. The graphics could be made even more difficult to OCR by mixing in words and pictures to represent the numbers. An even better solution may be to have the imagemap generated by the server and just the mouse clicks sent back to be decoded on the server. That is how server side imagemaps work now over the web. It shouldn't be hard to take credit card numbers this way. Weld Pond - weld@l0pht.com - http://www.l0pht.com/ L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio L0pht Open House 2/3/96 at 8:00pm - Live on irc #l0pht - write root@l0pht.com for details.
Weld Pond wrote:
Programs needing secure entry create a "secure entry field" which is really just an imagemap with the digits (and alphas if required) placed randomly about. The user then uses the mouse to click on these numerals. Ideally the graphics that represent the numerals would be drawn from a random pool and are misformed to thwart any OCR attempts. The graphics could be made even more difficult to OCR by mixing in words and pictures to represent the numbers.
The web page could be implemented with javascript, which could collect the keyclicks without any round trips to the server, and just send the encrypted credit card number. --Jeff -- Jeff Weinstein - Electronic Munitions Specialist Netscape Communication Corporation jsw@netscape.com - http://home.netscape.com/people/jsw Any opinions expressed above are mine.
Excerpts from mail: 29-Jan-96 Re: FV Demonstrates Fatal F.. Weld Pond@l0pht.com (1606*)
But take away the inputting of the credit card number via keystroke and the flaw disappears. How would your program deal with a scheme like this?
Yes, this is a good point, and is one of the approaches we thought of for defeating this attack. But bear in mind that our current attack is targeted against the current input method -- keystrokes. Any fixed input method is vulnerable to a similar attack. For instance:
Programs needing secure entry create a "secure entry field" which is really just an imagemap with the digits (and alphas if required) placed randomly about. The user then uses the mouse to click on these numerals. Ideally the graphics that represent the numerals would be drawn from a random pool and are misformed to thwart any OCR attempts. The graphics could be made even more difficult to OCR by mixing in words and pictures to represent the numbers.
If any particular program for doing this came into widespread use, we could engineer an attack, similar to our keystroke attack, based on the specific properties of the approach used. For example, changing the fonts is a good idea -- I had thought of that -- but if you put the numerals in boxes in the same relative positions each time, we can find that. Ultimately, if you really want commerce to work for hundreds of millions of people, there will need to be a standard interface, and if it makes the inputting of credit card numbers too regular, it can easily be attacked. If it makes it too irregular, consumers will probably rebel against it as "too hard to use". I haven't seen a good middle ground yet. Credit card numbers are so regular that the only way to hide their input is with a very irregular interface, which consumers are likely to hate.
An even better solution may be to have the imagemap generated by the server and just the mouse clicks sent back to be decoded on the server. That is how server side imagemaps work now over the web. It shouldn't be hard to take credit card numbers this way.
I've actually used one site that takes a similar approach. Very painful to use, which illustrates my point about the tradeoff. More generally, the tradeoff between security and usability shows up in many other places, it's just particularly acute and important when it comes to the entry of credit card numbers. -- Nathanel -------- Nathaniel Borenstein <nsb@fv.com> Chief Scientist, First Virtual Holdings FAQ & PGP key: nsb+faq@nsb.fv.com
participants (3)
-
Jeff Weinstein -
Nathaniel Borenstein -
Weld Pond