[OpenID] Security related Use Cases?

[Ben Laurie]

On Sat, Oct 18, 2008 at 1:26 AM, Eric Sachs <esachs at google.com> wrote:
>>> 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.
> 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.
> Last week we finished some related research in this space which I just
> published, along with a prototype you can play with here:
>
> http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
>
> 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.
>
> 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.

Second factors are not the only way forward here - simply using
passwords properly could more-or-less eliminate phishing.

>
> On Fri, Oct 17, 2008 at 2:58 PM, Dick Hardt <dick at sxip.com> wrote:
>>
>> On 17-Oct-08, at 1:13 PM, Eric Sachs wrote:
>>
>> >> 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?
>> The research note we published has a section on this which I have copied
>> below:
>> Phishing Increase
>> 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.
>>
>> Just to clarify, you did NOT do any testing?
>> 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.
>> 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.
>> 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.
>> What are your thoughts / concerns on this?
>> -- Dick
>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
>