Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

RE: Proposal to anti-phishing

Subject: RE: Proposal to anti-phishing
Date: Sat, 22 Jan 2005 00:41:11 -0800 (PST)
The scheme described by Frank is more of MACing
instead of OTP, meaning its uses the unique secret key
to perform the MAC (message authentication code)
against the field entered by the token holder. Not all
tokens is able to do this....at least I know RSA
SecureID is not able to do this. So the problem
describe by Lyal is still applicable if OTP token
(other than those from Vasco) is only use for user
authentication.


Regards
Sam


--- Frank Knobbe <frank@knobbe.us> wrote:

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 part 2 application/pgp-signature
name=signature.asc




                
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 

<Prev in Thread] Current Thread [Next in Thread>