[LINK] Security tokens
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
More information about the Link