<div dir="ltr"><div>>> <span style="border-collapse:collapse">Many people in the community view that having something on the client is the only way to minimize phishing. Wether that be a cookie, client side cert, add-on or smart browser.</span></div>
<div><span style="border-collapse:collapse">In addition to the identity community, at Google we have enterprise customers who use our corporate E-mail outsourcing service, and some of them already run SAML IDPs where they authenticate users with a second factor auth. However one of the their big complaints is that this does not work well with Google because we only support federated login from our browser application and not our rich-client apps (like Google Talk & the Blackberry Gmail J2ME app, amoung others). Some enterprises have even had to disable their SAML IDPs just because of the pressure from employees/executives to access those rich-client applications. Many other major SaaS vendors who act as SAML RPs have encountered the same problem, so I have been working with some of those vendors as well as some enterprise technology vendors to come up with alternatives. While we get these complaints from enterprises for our live systems, we have experimented in the past with 2ndFactorAuth with our consumers, and we ran into the same problem, but for consumers we have even more rich-client apps.</span></div>
<div><span style="border-collapse:collapse"><br></span></div><div><span style="border-collapse:collapse">Last week we finished some related research in this space which I just published, along with a prototype you can play with here:</span><br>
</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><a href="http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps" target="_blank">http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps</a> <br>
</blockquote><div>We certainly do not consider this a solved problem, but some progress is being made, and most of these techniques should work for consumers just as they do for enterprise users.<br></div><div><br></div>
<div>
You will notice that the research we did is not for any specific 2ndFactorAuth technology. There are a range of different options in the market, so what we hope to do is find an approach that is generic enough that different 2ndFactorAuth vendors & service providers can then innovate and find approaches for different market segments based on their balance of needs for security & usability. In just the last few days I started sending this research out to vendors of different 2ndFactorAuth solutions to see how it works with their products, and to see if we could get some demos of using 2ndFactorAuth with this technique in time for IIW.</div>
<span style="border-collapse:collapse"><div><br></div><div><br></div></span><div class="gmail_quote">On Fri, Oct 17, 2008 at 2:58 PM, Dick Hardt <span dir="ltr"><<a href="mailto:dick@sxip.com" target="_blank">dick@sxip.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br><div><div>On 17-Oct-08, at 1:13 PM, Eric Sachs wrote:</div><blockquote type="cite">
<div dir="ltr"><div><span style="border-collapse:collapse">>> <span>Have you tested the OP user experience with a malicious RP? ie. how easy is it for a malicious RP to fool users to pretend they are your OP?</span></span></div>
<div><span style="border-collapse:collapse">The research note we published has a section on this which I have copied below:</span></div><div><span style="border-collapse:collapse"><br> </span></div><div><span style="border-collapse:collapse"><span style="font-family:Arial"><b>Phishing Increase</b><br>
Some potential IDPs will be concerned that becoming an IDP will make it easier for their end-users to fall prey to phishing attacks. That is because an "evil" RP could intercept the user when they would normally be sent to the IDP, and instead show the user what looks like a login page for their IDP. The RP could then use that phishing page to collect the user's credentials. We do not have a magic answer for that problem. A similar problem also exists with web delegation protocols like OAuth. In the case of web delegation protocols, the user demand for access to their data was too high for websites to ignore, especially when users would give their credentials to 3rd party sites which would then scrape the main site for the user's data (such as social networks scraping a user's E-mail address book). End-users have a similar demand for federated identity, and because of the lack of it, many users will simply use their exact same password on their E-mail provider's site as they do on many other sites where they login with that same E-mail address. It will be up to individual IDPs to decide how to balance demands from their end-users with concerns about potential increases in phishing attacks.</span></span></div>
</div></blockquote><br></div></div><div>Just to clarify, you did NOT do any testing? </div><div><br></div><div>Many people in the community view that having something on the client is the only way to minimize phishing. Wether that be a cookie, client side cert, add-on or smart browser.</div>
<div><br></div><div>An enhanced browser would be able to control where the user is directed and provided a UX that cannot be duplicated by a phisher. An enhanced browser could also take over the UX for a user when the encounter a site that accepts OpenID -- providing a significantly more streamlined UX. </div>
<div><br></div><div>The browser vendors have indicated they would include functionality if they knew what to do. In the interim, IdP's like Yahoo! and Google could have a simple add-on off of their site that comes pre-configured for Yahoo! or Google.</div>
<div><br></div><div>What are your thoughts / concerns on this?</div><div><br></div><font color="#888888"><div>-- Dick</div><br></font></div></blockquote></div><br></div>