[LINK] Security tokens

Stephen Wilson swilson at lockstep.com.au
Thu Nov 15 12:00:23 AEDT 2007


David Lochrin wrote:

> One bank, to take an example, only requests a token password when a
> user first establishes a session so a man-in-the-middle (MIM)
> attacker could presumably hijack the session after that point and
> take their time to do what they pleased.
> It would be much better to request a token password when committing
> any "sensitive" (involving transfer of funds) transaction because the
> password could then be tied to the particular transaction.  It would
> have to be entered at a point in the user dialogue where the server
> asks for confirmation of a transaction it has already set up.

I agree.  For defined "sensitive" transactions, some precise user 
intervention should be captured.  In privacy sensitive applications, 
this also relates to consent.

IMHO the best way to involve the user in a verifiable way in a 
transaction is through a digital signature that binds a key under their 
control to the transaction.  Such a key should be secure within a 
personal device (and users should have access to a plurality of keys 
across different applications and domains).  Password based mechanisms 
only produce circumstantial evidence that the user holding a particular 
device was involved.  Further, the ability to verify that evidence (by 
looking up audit logs and OTP verification sequences) is seriously 
eroded by (a) time, and (b) 'distance'.  In open systems, it is awkward 
and risky for parties outside the OTP token server operator to access 
the logs and check the evidence.  On the other hand, a digital signature 
applied using, say, a customer's smartcard can be verified at 
essentially anytime down the track (even long after the certificates 
expire), and verification does not entail examining audit logs.

> Having said that, I think all banks would use an SSL connection for
> the full duration of each browser session and I believe SSL provides
> good protection against MIM attacks.  

Yes but only when the user is *sure* they have an SSL connection.  The 
recent attacks on SSL public keys, some of which are described in my 
whitepaper, render the SSL padlock unreliable.  An alert user might know 
to look out for the padlock, but its appearance is no longer a sure sign.

 > Even so, use of token passwords
> when committing sensitive transactions would probably circumvent more
> sophisticated MIM attacks mediated by malware in a user's computer,
> if that's possible.

Yes it's possible.  The important thing is to get the user involved in 
confirming sensitive transactions.  This eliminates most MITM.  Account 
hijacking by malware remains a real concern, and can only really be 
countered by having an impenetrable control path between the user and 
the smartcard (assumption: malware cannot infect the card itself; at the 
moment this is a fair assumption, and one which can be substantiated by 
security evaluation, since smartcard executable code is nice and 
compact). Some elements of building an impenetrable control path include 
(a) a tamper resistant reader with separate PIN pad ... such a thing 
might come standard one day, aided by the increasingly popular Trusted 
Platform Module in PCs, and (b) user interfaces where the smartcard 
itself generates secure messages to the user to show what's happening 
per transaction ... in other words, "WYWIWYS" or "What You See Is What 
You Sign.

Cheers,

Steve Wilson.




More information about the Link mailing list