[OpenID] Security related Use Cases?

[Eric Sachs]

>> What does the user do when they come back to an RP,  but don't remember
if they have used OpenID, can't remember their provider or identifier, or no
longer have an account with the OP?
When we talked with RPs, they raised a related concern:  Here is quote from
the user research we published at
http://sites.google.com/site/oauthgoog/UXFedLogin

However, if that IDP disables their IDP verification service, or it becomes
unstable, then the RP cannot authenticate the users from that domain.
 Therefore, a more conservative RP is likely to continue to require E-mail
addresses because they can be used as a backup way to authenticate users in
that situation by sending the user a traditional E-mail verification or
Forgot Password link.

I have talked with a bunch of potential E-Commerce RPs about advanced
"tricks" we could use to get them to no longer need to store the user's
E-mail.  However nearly all of them said they are going to require knowledge
of the user's E-mail as a backup in case the IDP becomes untrustworthy.

However if the user "no longer has an account with the OP" and the OP is
also the user's E-mail provider, then the RP won't be able to use the forgot
password link.  Potential E-Commerce RPs are not happy with that, but seem
to consider it a relatively minor issue.

As to your more generic question about users who don't remember if they have
used an OP/IDP, or can't remember the OP, that isn't really a problem if the
RP's login box asks the user for their E-mail address and then uses the
domain for OpenID Directed Discovery.  Or at least, it is know more of a
problem then the current situation where a user might forgot which of their
E-mail addresses they used at a particular RP.  However I agree that this is
a bigger problem if the RP offers multiple ways for the user to login (such
as IDP buttons as well as regular E-mail/username + password).

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



On Fri, Oct 17, 2008 at 11:44 AM, Dick Hardt <dick at sxip.com> wrote:

> Allen / Eric
>
> I was wondering if you have thought through a couple of security related
> scenarios:
>
> Identifier Recover / Reset:
>
> What does the user do when they come back to an RP,  but don't remember if
> they have used OpenID, can't remember their provider or identifier, or no
> longer have an account with the OP?
> Casual sites will usually reset the password over email.
>
> Malicious RP:
>
> 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?
>
> -- Dick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081017/2234fd28/attachment-0002.htm>