and IMHO, any solution that doesn't let the user type his password
into some Web form is a non-starter, both for reasons of backward
compatibility and because sites (quite
legitimately) want to provide a
visually attractive interface to users which is consistent
across all
At Thu, 13 Sep 2007 12:21:48 +0100,
[EMAIL PROTECTED] wrote:
and IMHO, any solution that doesn't let the user type his password
into some Web form is a non-starter, both for reasons of backward
compatibility and because sites (quite
legitimately) want to provide a
visually
So much for typing. How about selecting password letters
from dropdown
boxes, or from an image map with scrambled letters that was sent to
the browser.
Sorry, what about these? They have essentially the same
security properties as cleartext passwords.
One would hope that all
At Thu, 13 Sep 2007 16:14:47 +0100,
[EMAIL PROTECTED] wrote:
So much for typing. How about selecting password letters
from dropdown
boxes, or from an image map with scrambled letters that was sent to
the browser.
Sorry, what about these? They have essentially the same
.
From: Eric Rescorla [mailto:[EMAIL PROTECTED]
Sent: Thu 13/09/2007 11:27 AM
To: [EMAIL PROTECTED]
Cc: ietf@ietf.org
Subject: Re: Symptoms vs. Causes
At Thu, 13 Sep 2007 16:14:47 +0100,
[EMAIL PROTECTED] wrote:
So much for typing. How about selecting password letters
from
There are a large number of protocol designs--even existing
protocols--which are compatible with the general paradigm of user U
proves possession of password P to server A without giving A a
credential which can be used to impersonate U to server B.
HTTP Digest, TLS-PSK, SRP, and PwdHash all
Eric Rescorla wrote:
In the end 'phishing' is about UI and not protocols.
Quite so.
It's about both. We can severely limit phishing through the use of
mutual authentication. The UI part is that whatever mutual
authentication you use has to be both mandatory AND easy to use. The
The entire issue depends to some extend also on the communication model
you have in mind.
If you consider an approach that is closer to SAML or OpenID then the
end host interacts with the identity provider directly. If you, however,
focus on something that is close to the AAA model then the
, September 12, 2007 3:59 AM
To: Eric Rescorla
Cc: ietf@ietf.org
Subject: Re: Symptoms vs. Causes
Eric Rescorla wrote:
In the end 'phishing' is about UI and not protocols.
Quite so.
It's about both. We can severely limit phishing through the use of mutual
authentication. The UI part
Christian Huitema wrote:
There are a large number of protocol designs--even existing
protocols--which are compatible with the general paradigm of user U
proves possession of password P to server A without giving A a
credential which can be used to impersonate U to server B.
HTTP Digest, TLS-PSK,
/2007 8:05 AM
To: Christian Huitema
Cc: ietf@ietf.org
Subject: Re: Symptoms vs. Causes
Christian Huitema wrote:
There are a large number of protocol designs--even existing
protocols--which are compatible with the general paradigm of user U
proves possession of password P to server A without
At Wed, 12 Sep 2007 00:51:33 -0700,
Christian Huitema wrote:
There are a large number of protocol designs--even existing
protocols--which are compatible with the general paradigm of user U
proves possession of password P to server A without giving A a
credential which can be used to
At Wed, 12 Sep 2007 09:59:25 +0200,
Eliot Lear wrote:
[1 text/plain; ISO-8859-1 (7bit)]
Eric Rescorla wrote:
In the end 'phishing' is about UI and not protocols.
Quite so.
It's about both. We can severely limit phishing through the use of
mutual authentication.
This
Eric,
As I noted in my review, we already have a number of protocols which
potentially provide this functionality, including mutual authentication.
And I think looking at protocols without an understanding of how they
are used and how they interact with the UI is just as wrong as
At Wed, 12 Sep 2007 16:20:09 +0200,
Eliot Lear wrote:
Eric,
As I noted in my review, we already have a number of protocols which
potentially provide this functionality, including mutual authentication.
And I think looking at protocols without an understanding of how they
are used
Eric Rescorla wrote:
None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this
problem--provided that the user actually uses the new authentication
method and doesn't type his password into some Web form. But of
course that's a UI problem, not a protocol problem.
As I wrote, the
At Wed, 12 Sep 2007 16:32:34 +0200,
Eliot Lear wrote:
Eric Rescorla wrote:
None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this
problem--provided that the user actually uses the new authentication
method and doesn't type his password into some Web form. But of
course that's
Erik,
You have to put the two together. If we do, we find that we can solve
the UI problem by taking authentication OUT of known insecure
components. But that requires a protocol to that authentication
component. If one exists, what is it? It requires process
interactions. What are
Eric,
Each of these approaches has a fairly obvious architecture. In fact,
Digest, which I forgot to mention in my previous message,
already has a pre-existing architecture, and PwdHash works with
the existing architecture.
You have to put the two together. ALL of the approaches that you
At Wed, 12 Sep 2007 16:58:12 +0200,
Eliot Lear wrote:
Erik,
Eric.
You have to put the two together. If we do, we find that we can solve
the UI problem by taking authentication OUT of known insecure
components. But that requires a protocol to that authentication
component. If one
At Wed, 12 Sep 2007 17:08:05 +0200,
Eliot Lear wrote:
Eric,
Each of these approaches has a fairly obvious architecture. In fact,
Digest, which I forgot to mention in my previous message,
already has a pre-existing architecture, and PwdHash works with
the existing architecture.
Eric Rescorla wrote:
What's an authentication module? You seem to be assuming a particular
system architecture that you haven't laid out.
Many others have. I myself did so in a USENIX Login: Winter Security
issue some years ago. SubOS would be a software example. Potentially
CardSpace
And I think looking at protocols without an understanding of how they
are used and how they interact with the UI is just as wrong as
attempting to fix the problem simply within the UI. You wrote that some
mechanisms could be made to work. You might be right, but I'm not
convinced.
At Wed, 12 Sep 2007 11:27:07 -0400,
Keith Moore wrote:
And I think looking at protocols without an understanding of how they
are used and how they interact with the UI is just as wrong as
attempting to fix the problem simply within the UI. You wrote that some
mechanisms could be
None of the systems I mentioned (TLS-PSK, SRP, PwdHash) has this
problem--provided that the user actually uses the new authentication
method and doesn't type his password into some Web form. But of
course that's a UI problem, not a protocol problem.
and IMHO, any solution that
And one that W3C is currently working on.
I am on the W3C Web Security Context call at this very minute.
From: Eliot Lear [mailto:[EMAIL PROTECTED]
Sent: Wed 12/09/2007 10:20 AM
To: Eric Rescorla
Cc: ietf@ietf.org; Eliot Lear
Subject: Re: Symptoms vs
this to the IRTF and start an interest/research group there if we are
going to do anything.
From: Keith Moore [mailto:[EMAIL PROTECTED]
Sent: Wed 12/09/2007 11:39 AM
To: Eric Rescorla
Cc: ietf@ietf.org; Eliot Lear
Subject: Re: Symptoms vs. Causes
None
Michael Dillon said:
Personally, I would like to see some more criticism of the fact that
this draft is about Phishing, a symptom of security problems, rather
than about strengthening a weakness in Internet security. It is entirely
possible to solve the phishing problem without strengthening
Shumon == Shumon Huque [EMAIL PROTECTED] writes:
Shumon And yes, I agree that a new properly designed version of
Shumon HTTP Digest authentication might be one way to help. As
Shumon well as the various zero knowledge protocols.
I believe that http digest plus channel bindings does
Actually, a fundamental problem with the current protocol is that there
was little attention paid to the requirements of UI design experts. The
natural result is that application developers worked with what they had to
produce an interface usable by their average user. Any critique of the
David Morris wrote:
Actually, a fundamental problem with the current protocol is that there
was little attention paid to the requirements of UI design experts. The
natural result is that application developers worked with what they had to
produce an interface usable by their average user. Any
[EMAIL PROTECTED] said:
In the end 'phishing' is about UI and not protocols.
+1 sorta, in that I feel this build on the above is appropriate..
In the end 'phishing' is about UI, and also about protocols, to the extent
the latter influence and/or enable UI particulars.
E.g. HTTP+HTML's
I certainly agree with attacking the cause rather than symptom. But a
portion of Sam Hartman's draft is in fact dealing with a cause of the
symptom. Namely the part that is trying to protect user credentials
from disclosure to an unauthorized party -- by proposing to eliminate
the near
At Tue, 11 Sep 2007 13:55:54 -0700 (PDT),
David Morris wrote:
Actually, a fundamental problem with the current protocol is that there
was little attention paid to the requirements of UI design experts. The
natural result is that application developers worked with what they had to
produce an
Michael Dillon said:
Personally, I would like to see some more criticism of the fact that
this draft is about Phishing, a symptom of security problems, rather
than about strengthening a weakness in Internet security. It is entirely
possible to solve the phishing problem without strengthening the
35 matches
Mail list logo
