<!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">
Hi Andrew,<br>
<br>
Thanks for the follow up, as Breno and I have stated a few times, we
believe that from an anti-phishing perspective, the popup is equivalent
to the existing full browser redirect UI. If the concern is that the
browser chrome is spoofed in HTML, then I believe the special EV cert
green address bar visual indicator would also be vulnerable to spoofing
on IE and Firefox, although the treatment might be more spoofing
resistant on Safari (the visual indicator appears in the browser's
title bar).<br>
<br>
The PAPE WG has defined a framework for users to be authenticated using
phishing resistant authentication policies, so RPs and OPs that require
phishing resistant authentication should look into the PAPE extension.
PAPE is orthogonal to the Popup extension, and both extensions can be
implemented simultaneously.<br>
<br>
Thanks<br>
Allen<br>
<br>
Nash, Andrew wrote:
<blockquote
cite="mid:859A88E15EE29A4689B00C6F53C0BB6D02D2C534@RHV-EXM-04.corp.ebay.com"
type="cite">
<pre wrap="">
Hi Allen,
Thanks for taking time to clarify the points of discussion (my apologies
for the late response - other responsibilities kept me from addressing
this).
As you folks at Yahoo are well aware, the biggest challenge from a UI
perspective is that the bad guys do not play by the rules. If there is
something that can be used as a visual queue - in almost all cases the
same visual queues can be replicated. The upshot is that we can create
an environment in which users are lulled into a false sense of security.
Providing the visual queues of an address bar may or may not be useful.
Do you expect that there will be a facility as part of your scheme that
will ensure that a site's SSL certificate (in PayPal's case an EV cert)
can be used to verify the address bar contents? If an address bar is
simply a visual queue with no supporting validation mechanism, then a
spoof RP will simply render an address bar with the correct URL for the
IDP and we have achieved nothing but ensuring that users are more easily
fooled.
This is the basis of my problem with the fundamental assumption of the
WG - I have yet to see a solution in this space that actually works -
and we have look at this problem on an almost daily basis.
If you have something that fundamentally changes the equation here in a
trusted fashion I would be delighted to hear about it. I am like
everyone else completely aware of the desirability of a more clean user
experience for authentication - not just with OpenID.
--Andrew
-----Original Message-----
From: Allen Tom [<a class="moz-txt-link-freetext" href="mailto:atom@yahoo-inc.com">mailto:atom@yahoo-inc.com</a>]
Sent: Thursday, March 19, 2009 7:07 PM
To: Nash, Andrew; <a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
Subject: Re: [OpenID] OpenID User Interface Working Group
Hi Andrew,
I am in total agreement with you that phishing is a huge problem, and
the Yahoo Membership team (the same folks working on OpenID) devotes a
considerable amount of resources to fight phishing, and well as trying
to help users who have been phished.
We also put in a lot of effort to educate users about phishing, and we
strongly encourage our users to setup a personalized anti-phishing
Sign-in Seal, as well as to always check the address bar of the browser
before entering their Yahoo credentials.
<a class="moz-txt-link-freetext" href="http://security.yahoo.com/article.html?aid=2006102503">http://security.yahoo.com/article.html?aid=2006102503</a>
<a class="moz-txt-link-freetext" href="https://protect.login.yahoo.com/">https://protect.login.yahoo.com/</a>
<a class="moz-txt-link-freetext" href="http://openid.yahoo.com/">http://openid.yahoo.com/</a> (Click on the OpenID Tour link to learn about
phishing and OpenID)
We are totally against the concept of allowing an RP to open a frame for
the user to enter their OP's password. As you pointed out, the user
would have no idea where the password is going, and this would be
extremely insecure. Earlier versions of Facebook Connect used to
demonstrate this behavior, and I'm very glad to see that Facebook has
since moved the password validation into a standalone popup window, with
the browser's addressbar clearly displayed.
One of Yahoo's primary security requirements with Federated SSO (OpenID,
OAuth, BBAuth, SAML) is that the user is able to recognize the Yahoo
Login screen. We do this by educating users to always check the address
bar and to create a customized Sign-in Seal. The UI Working Group
believes that a popup authentication screen, in a standalone browser
window (not framed) and with the address bar clearly displayed,
providers users with the same ability to detect phishing compared to the
existing full browser redirect user experience that is used by OpenID
today.
From a user experience perspective, eliminating the browser redirect
maintains the context of the RP's site, which is the biggest complaint
that we've received with BBAuth, OAuth, and OpenID. Facebook, Yahoo,
many others have UX research showing that the redirect is a very jarring
experience, and the success rate can be dramatically improved by moving
to a popup flow.
As far as I can tell, an independent popup window, with the address bar
displayed, has the same characteristics with regards to phishing, as the
full browser redirect. The popup window does not prevent OPs from
deploying anti-phishing technologies, and I believe that the popup will
drive more widespread usage of OpenID, which will also increase demand
for anti-phishing solutions.
thanks
Allen
Nash, Andrew wrote:
</pre>
<blockquote type="cite">
<pre wrap="">One of the ways that we have been able to reduce the incidence of
successful account takeovers has been to drill into consumers that
they should NEVER sign into an account on a domain that is not
directly associated with the account provider. This is not perfect,
but then none of the anti-phishing techniques are - it is why we have
to spend so much money and utilize so many different strategies.
As it reads, UI working group will be socializing the concept among
users that it is perfectly fine to enter your authentication
information at any site that pops up a frame asking for it. From an
Internet trust perspective this is a REALLY BAD IDEA!
OpenID is already criticized for its exposure to phishing and spoofing
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">attacks. If this approach is taken in the way it seems to be
described, we will pretty much ensure that no one that has medium to
high value transactions or services will be interested in implementing
</pre>
</blockquote>
<pre wrap=""><!---->OpenID.
</pre>
<blockquote type="cite">
<pre wrap="">--Andrew
_______________________________________________
general mailing list
<a class="moz-txt-link-abbreviated" href="mailto:general@openid.net">general@openid.net</a>
<a class="moz-txt-link-freetext" href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>