You're right - there are 2 token models - the simple OTP approach I
discussed, and the integrated transaction processing tokens.
The second model assumes that the user's machine is not infected with
spyware/backdoor trojans.
In the event the user's machine is infected, it is a trivial process to link
the serial No of the device to the user, by a) querying the device, and b)
sniffing the user's authentication and c) sent to a central hacker's
database. Need a) was docuemnted by Microsofts Smartcard demo programs in
1998, keyboard sniffers have been around longer (biometric sniffers are a
coding exercise for the student) and graphical password sniffers were
demo'ed in 1997 to my knowledge.
This tuple can then be queried any time the token is plugged into an
infected machine, and used to authenticate multiple trasactions - the one
the user intended, and those the hacker intends.
The result: the bank still doesn't know which transactions are real, but
remains liable for guessing wrong.
Preventing these issues has conventionally meant putting a keypad and
display screen into the token, and electonic links between token and the
user's machine (manual reentry of transaction details is too messy for
customers). Overall, in my experience this pushes up the cost per token to
~$200 best case, and $1000+ in the worst case, once shipping, device power,
customer support and software compatibility are managed for a good customer
experience. Since fraud is nowhere these levels, the costs significantly
outweigh the advantages.
Lyal
-----Original Message-----
From: Frank Knobbe [mailto:frank@knobbe.us]
Sent: Monday, 17 January 2005 7:25 AM
To: Lyal Collins
Cc: webappsec@securityfocus.com
Subject: RE: Proposal to anti-phishing
On Sun, 2005-01-16 at 17:38 +1100, Lyal Collins wrote:
To eapnd on this, there is nothing the stop the phisher capturing the
entire
session (i.e MITM tunneling), even using a valid OTP token to logon, and
even a second OTP token to 'authenticate' a transaciton.
With tunneling the entire session, the attacker can easily present the
user
with screens saying "transfer $200 to mum" while telling the banking site
to
'transfer $1000 to joe@hacking.site.somewhere"
Not quite correct. Obviously you haven't used these token schemes.
Most transactions that are authenticated/confirmed by tokens do include
the values themselves. For example:
Src Acct: 123-456
Dst Acct: 333-222
Amount: $1,000,000
AuthCode: (to be entered by user from token)
The user receives/enters the values above, enters these into his token
which will present a unique value (auth code) tied to his token, but
also to the values. That means if a MITM hacker changes an account
number or other value, the authentication code would different. Since
the attacker does not have access to the users token, he can not
generate a correct authentication code, and thus the transaction is
invalid.
Vasco's tokens are widely used amongst the financial industry (perhaps
more so in Europe then the US). Back in the mid-late nineties when I
worked with these tokens, they had a nice demo on their website that
would explain/test the process. It could be used with their physical
demo tokens, or the virtual token online. If you like further info on
this process and a demo, see their web page. Maybe the demo is still
online.
In summary: Tokens don't just authenticate the user or the session, they
are also used to authenticate *transactions*, which is exactly how MITM
attacks are defeated. An attacker intercepting the transaction can not
change values without invalidating the authentication code.
Regards,
Frank
