[OpenID] security weakness regarding authentication of the relying party

[Francisco Corella]

Hi Paul,

Thanks for the reply, and sorry for my late reply.

> I took a brief look at your paper and it seemed to suggest
> that users might be duped by similar-looking domain names,
> but that is human error, not protocol error.  Is that the
> point?

Actually there are two problems.

The first problem is what you say, users may be duped by
similar-looking domain names.  This may not be a protocol
error, but it is an exploitable security weakness, and one
that can be addressed: there are better ways of identifying
the relying party to the user than a domain name.  

This is not user error, users are not required to study
domain name syntax before using the Web.  And some OpenID
products rely on users misinterpreting domain names.  The
free version of Janrain Engage identifies the RP as
example.rpx.com after being redirected from example.com.  A
user who understands domain name syntax should refuse to
continue, but apparently nobody does!

The second problem is that the spec does not seem to require
nor even recommend the use of SSL by the RP for the
return_to URL.  Section 15.1.2 "strongly recommends" the use
of SSL, but it is only talking about the OP.

Without using SSL for the return_to URL, an attacker can set
up a man-in-the-middle attack on the connection between the
browser and the RP.  After user authentication with the OP,
the attacker can intercept the positive assertion, terminate
the connection with the legitimate user, and impersonate the
user vis-a-vis the RP using the positive assertion.

Man-in-the-middle attacks are easy to set up using
ready-to-use tools, judging from instructions available on
the Web.

Francisco

--- On Fri, 1/14/11, Paul E. Jones <paulej at packetizer.com> wrote:

From: Paul E. Jones <paulej at packetizer.com>
Subject: RE: [OpenID] security weakness regarding authentication of the relying party
To: fcorella at pomcor.com, openid-general at lists.openid.net
Date: Friday, January 14, 2011, 11:39 PM

Late to reply to this, but I didn’t see other replies…  It does not “authenticate” the realm, but if a request arrives for realm good_site.example.com, then a positive assertion will only be provided if the return URL is properly is a part of that that realm (i.e., same name or perhaps a sub-domain thereof).  So, there is some checking.  A positive assertion will not be returned to bad_site.example.org, for example.  So, exactly what is the security issue? I’ll not deny there is one, but it is not clear to me.  I took a brief look at your paper and it seemed to suggest that users might be duped by similar-looking domain names, but that is human error, not protocol error.  Is that the point?  Paul  From: openid-general-bounces at lists.openid.net [mailto:openid-general-bounces at lists.openid.net] On Behalf Of Francisco Corella
Sent: Wednesday, December 22, 2010 2:13 PM
To: openid-general at lists.openid.net
Subject: [OpenID] security weakness regarding authentication of the relying party  Hi all,

There is a security weakness in OpenID which may be already
known but is not discussed in the security considerations
section of the specification.  It hinges on the fact that
the OpenID provider does not authenticate the relying party.
I discuss the issue in detail in a paper.

OAuth solves this problem in theory by requiring the OAuth
client (the relying party) to register with the OAuth
server.  But Google and Yahoo allow unregistered
applications, so the problem remains.  Btw compulsory
registration is a bad idea: imagine a situation where
a social site becomes dominant, social login via that site
becomes the de facto authentication standard on the Web,
every application has to register with the site, and the
site can kill any application by revoking its registration.

The paper proposes a solution to all this.  Thanks in
advance for any comments.

-- Francisco  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20110118/5a8047f5/attachment.html>