<HTML><BODY>
<div>I believe that option #2 is the correct one to recommend at this time. While this is clearly outside of the openID protocol itself, remaining silent on the potential phishing attacks is not going to help promote openID in the long term.<br>
</div>
<br>
Unless other mechanism are in place to prevent phishing (see below) the OP must:<br>
<br>
1) suggest that users login to the Open ID provider prior to accessing any Open ID-enable site.<br>
2) refuse to display a login page in response to an authentication request. Instead, the OP must direct the user to navigate to the OP on their own, by using a bookmark or typing in the URL directly. NOTE: the OP may record the authentication request for this user, and continue the processing the request after credentials have been presented.<br>
<br>
These constitute the most basic defense against phishing.<br>
<br>
The OP may provide other measures to prevent phishing, such as:<br>
1) using some form of credential that guards against phishing (SRP, site-specific password digests, Cardspace, public keys, full PKI...)<br>
2) personalized content on the login page, together with educating the user to look for the content (Yahoo, Bank of America...)<br>
3) detecting the presense of appropriate client extensions that guard against spoofing. (petname toolbars etc)<br>
<br>
Can we agree that this level of recommendation should be included in the protocol spec?<br>
<br>
Terry <br>
<br>
-----Original Message-----<br>
From: hgranqvist@verisign.com<br>
To: security@openid.net<br>
Sent: Mon, 22 Jan 2007 10:59 AM<br>
Subject: [security] Making phishing hard without changing UA side protocol<br>
<br>
<div id="AOLMsgPart_0_08dd9168-476f-41bb-9efa-ec510ed371db" class="AOLPlainTextBody">
<pre><tt>Just some quick thinking how phishing for passwords can
be diminished without severely changing the protocol or
enforcing UA plugins, etc.
1. The OP requires:
-- a RP must associate before the OP accepts it
(as a return_to/trustroot).
-- before OP allows such association, the RP must
provide an acceptable XRDS file(*).
2. The OP refuses to do a login at the same time
as an authentication. The user must be logged in
beforehand.
Of course, 2. is a user education, but maybe not that
hard to teach?
Does OpenID delegation change the assumptions?
-Hans
(*) The OP decides what is acceptable. The XRDS can
contain 3rd party-verifiable cryptographic tokens, for
example.
_______________________________________________
security mailing list
<a href="mailto:security%40openid.net">security@openid.net</a>
<a href="http://openid.net/mailman/listinfo/security" target="_blank">http://openid.net/mailman/listinfo/security</a>
</tt></pre>
</div>
<!-- end of AOLMsgPart_0_08dd9168-476f-41bb-9efa-ec510ed371db -->
<div class="AOLPromoFooter">
<hr style="margin-top:10px;" />
<a href="http://pr.atwola.com/promoclk/1615326657x4311227241x4298082137/aol?redir=http%3A%2F%2Fwww%2Eaol%2Ecom%2Fnewaol" target="_blank"><b>Check out the new AOL</b></a>. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more.<br />
</div>
</BODY></HTML>