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

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

Joerg Schwenk

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


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

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

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

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

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

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

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

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

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

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

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

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