<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">+1<br>
<br>
Phishing should have it's own entry in the security considerations
section.<br>
<br>
Thanks,<br>
George</font><br>
<br>
john kemp wrote:
<blockquote cite="mid45C34B07.1050405@mac.com" type="cite">
<pre wrap="">Hi Josh,
In addition to the protocol parameter that you have proposed, I'd hope
that we can add something like what you wrote below as part of the
security considerations section of the OpenID 2.0 Auth specification, as
this text seems to capture quite succinctly the issues that RPs and OPs
should be thinking about when attempting to deal with phishing:
Josh Hoyt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The ways that OpenID can potentially make phishing worse:
* Redirects to your provider are a fundamental part of the flow of
OpenID, so being redirected to a phishing site is easy to miss
* Every relying party (necessarily) needs to know who the provider
is in order to verify the authentication response. This means that the
site knows what UI it needs to use to phish (and even worse, it can
just proxy the user to the provider)
I think these two issues cover what makes phishing potentially a
greater threat when using OpenID.
Although these problems are significant, if a user can authenticate to
their OpenID provider through an "non-phishable" mechanism, OpenID can
make the phishing problem *less* of a threat, because there are fewer
places that will need to ask for credentials.
Other relevant issues:
* There is no universally deployed solution to the phishing problem
* There is not even a universally *accepted* solution to the phishing problem
* Any technology that prevents phishing will require user-agent
support or else will fundamentally change the flow of OpenID (prevent
relying-party-initiated sign-in)
* OpenID is intended to be deployed without requiring specific
technologies to be present in the user-agent
</pre>
</blockquote>
<pre wrap=""><!---->
It might also be helpful to add somewhere a specific definition of
phishing, and the associated attack - that an OP can steal a user's
credentials if they are passed to the OP. Mitigation can only really be
performed by applying client-side changes that ensure that long-lived
private information shared only between the OP and the user (such as a
password) does not pass across the network.
Regards,
- John
_______________________________________________
specs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:specs@openid.net">specs@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/specs">http://openid.net/mailman/listinfo/specs</a>
</pre>
</blockquote>
</body>
</html>