[OpenID] Security related Use Cases?

[Eric Sachs]

>> 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.


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081017/f4bf002b/attachment-0002.htm>