Re: AW: AW: Magic Bullet (proposal for in-browser secure 2-way authentication resistent to online and offline attacks)

Hi Jörg,

How is this a solution?  Giving the man in the middle both the
transaction number, and the answer to the random challenge still
enables him to do whatever he wants (allbeit just "now", as opposed to
anytime he wants "in future").

Are German banks doing anything to help tell the customer that they're
banking on the correct web site, and not some imitation phishing
version?

Have you got any data on why they're adopting this idea?  I don't
think there's a lot (any?) banking MiTM victims out there - at least -
definitely not any significant number as compared to phishing
victims?

My guess is that they're not protecting against MiTM at all, and
simply using disposable identifiers to minimize/limit phishing risks
to single-sessions.

Kind Regards,
Chris Drake


Thursday, March 15, 2007, 4:24:11 AM, you wrote:

JS> German banks are currently adopting some kind of "transaction aware OTP"
JS> solution: Customers have to type the target account number together with a
JS> random challenge into an OTP device. This seems to be a good solution
JS> against mitm attacks.

JS> Joerg

JS> -----Ursprüngliche Nachricht-----
JS> Von: Florian Weimer [mailto:fw@deneb.enyo.de] 
JS> Gesendet: Dienstag, 13. März 2007 10:49
JS> An: Dan Schutzer
JS> Cc: 'Chris Drake'; 'Jörg Schwenk'; 'James A. Donald';
JS> public-usable-authentication@w3.org
JS> Betreff: Re: AW: Magic Bullet (proposal for in-browser secure 2-way
JS> authentication resistent to online and offline attacks)

JS> * Dan Schutzer:

>> One time passwords are susceptible to real time man in the middle
>> attacks

JS> You don't even need real-time attacks, you just block every other
JS> transaction, claiming that the password has already been used, and
JS> have the Trojan horse send you those unused passwords.  That's why
JS> it's interesting to tie one-time passwords to particular transactions.

JS> There are very complex trade-offs involved, and the whole thing is a
JS> topic of ongoing research, on both sides.

>> Cookies can be insecure if they store sensitive information in the clear

JS> A lot of sensitive cookies are insecure because they aren't restricted
JS> to HTTPS. 8-(

Received on Thursday, 15 March 2007 11:04:27 UTC