WebApp Sec mailing list archives

RE: Proposal to anti-phishing


From: Frank Knobbe <frank () knobbe us>
Date: Sun, 16 Jan 2005 14:24:34 -0600

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

Attachment: signature.asc
Description: This is a digitally signed message part


Current thread: