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

Hi Chris,

the fundamental difference between cookies and client certs is that that ALL
the information contained in a cookie is sent to the server, whereas with a
client cert, only the public part is sent, the private key is never
transmitted. 

We have carried out some experiments with pharming and cookies and found
out, that cookies are sent whenever the browser thinks he is connected to
the right domain. Even SECURE cookies are sent aver SSL connections with
invalid server certificates. (The user has to click away some warnings.)

Hope this explains why I see a difference.

greetings

Joerg

-----Ursprüngliche Nachricht-----
Von: Chris Drake [mailto:christopher@pobox.com] 
Gesendet: Montag, 12. März 2007 23:42
An: Jörg Schwenk
Cc: 'James A. Donald'; public-usable-authentication@w3.org
Betreff: Re: AW: Magic Bullet (proposal for in-browser secure 2-way
authentication resistent to online and offline attacks)

Hi Jörg,

There's actually 2 way to lower the risk of both MiTM and Trojan
attacks - either prevent the attacks, or, design a system such that a
successful attack has no "sting" (eg: after the attack has been a
"success", the information gathered from it is useless - such as, for
example, using single-use-only disposable passwords)

Disabling browser plugins during SSL won't block Trojans (or if it
does, Trojans will evolve to not be browser plugins).  Avoiding
Trojans can be as simple as using tokens or a printed list of
single-use passwords, or as complex as in-browser graphic-based
authentication using anti-eavesdropping technology (or ideally - a
combination of both).

I disagree with your insecure cookie statement: can you explain *why*
cookie-based solutions are "not secure enough" ?  A cookie and a
client-side cert both live in files on a users hard drive: one is
optionally protected by a password on the file, the other is
optionally protected by a password on the computer.  One can be sent
to any web site on request, the other can be sent only to a specific
subset of SSL verified domains (assuming secure cookies are used
instead of just any old cookie).  Both are issued from some original
web site under that sites issuing policy.

Kind Regards,
Chris Drake


Monday, March 12, 2007, 9:13:05 PM, you wrote:

JS> The problem is to avoid man-in-the-middle attacks:
JS> - mitm attacks on the internet can be avoided; cookie based solutions
are
JS> not secure enough, SSL server authentication will never be fully
understood
JS> by users, but SSL client authentication may be a solution.
JS> - THE real problem today is mitm with Trojan horses: they have access to
JS> nearly any information available to the browser. A secure mode (where
all
JS> plugins are disabled when SSL is enabled) would be needed.

JS> Joerg Schwenk

JS> -----Ursprüngliche Nachricht-----
JS> Von: public-usable-authentication-request@w3.org
JS> [mailto:public-usable-authentication-request@w3.org] Im Auftrag von
James A.
JS> Donald
JS> Gesendet: Freitag, 9. März 2007 02:19
JS> An: Chris Drake
JS> Cc: public-usable-authentication@w3.org
JS> Betreff: Re: Magic Bullet (proposal for in-browser secure 2-way
JS> authentication resistent to online and offline attacks)


JS> Chris Drake wrote:
 >> So - to summarize - a fully authenticated login
 >> consists of the steps:
 >>
 >>  E) Enter username G) Enter password I) Click photo
 >>  hot-spot
 >>
 >> A re-authentication login consists of the step
 >>
 >>  I) Click photo hot-spot

JS> This works because the checking the presence of the
JS> correct photo becomes part of the workflow, part of the
JS> task at hand.

JS> If it is not part of the workflow, people just are not
JS> going to notice the presence or absence of the photo.

JS> Trouble is that the correct photo cannot necessarily be
JS> displayed until the user enters his username.

JS> So the counter counter measure is:
JS> 	Lure user to phishing site:  When user enters
JS> 	username on phishing site, phishing site enters
JS> 	username on real site.  Phishing site gets
JS> 	photo, displays photo to user.  User clicks on
JS> 	phishing site hot spot, phishing site clicks on
JS> 	photo on real site, then redirects user to main
JS> 	page of real site.

 >> Here is the list of threats that I hope my proposal
 >> mostly solves:-
 >>
 >> 
JS>
http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-July/000342.htm
JS> l

JS> Your fix seems irrelevant to most of these threats.  It
JS> will solve some of the most serious threats - provided
JS> the phishers do not take counter measures.  Your fix
JS> will work for some of the most serious threats - until
JS> it is widely applied.

JS> Ultimately, to fix the problem, we need a client side
JS> signon/login tool, which also enables the client to
JS> receive messages from entities with which the client has
JS> a login relationship, analogous to the buddy list in IM,
JS> and, like the buddy list in IM, only from those
JS> entities.

JS> The interface of the signon tool should resemble an IM
JS> interface, and also resemble the interface for a
JS> browser's favorites list.  However clicking on a
JS> "buddy", instead of opening a chat window with the
JS> buddy, brings you to the web page like a "favorite", but
JS> you are logged on, unlike a "favorite".  Clicking on a
JS> message, instead of opening a chat window, brings you
JS> logged on to a web page belonging to that "buddy", but a
JS> web page selected by the message author (a web page that
JS> normally contains the body of the message), instead of
JS> the web page corresponding to that "favorite".

JS> I am working on a tool to do this, but am not yet in a
JS> position to give an estimated delivery date.

JS> In the present incarnation of the tool, the three
JS> parties to an interaction are the single sign on server
JS> (SSS), the client, and the relying party.  The relying
JS> party is the web site the client wants to log in to, for
JS> example a bank or a blog.  the user has to logon with a
JS> single sign on server, but any relying party can use any
JS> sig

JS> As with an instant messaging system, user has to
JS> register and logon to a single signon server.  Any
JS> server will do.  So we then face the problem of making
JS> the signon server invulnerable to phishing:  One
JS> solution to that problem is SRP, and another other is to
JS> have a short list of public keys of permitted single
JS> signon servers, a list that the user can add to, but
JS> which is not easy to mindlessly do a one click add.