From: Nathaniel Borenstein <nsb@nsb.fv.com>
Date: Wed, 31 Jan 1996 23:48:45 +0800
To: weld@l0pht.com>
Subject: Re: FV Demonstrates Fatal Flaw in Software Encryption of Credit Cards
In-Reply-To: <Pine.BSD/.3.91.960129170118.14124A-100000@l0pht.com>
Message-ID: <cl3T04GMc50eQWY6Qp@nsb.fv.com>
MIME-Version: 1.0
Content-Type: text/plain


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