[OpenID] security weakness regarding authentication of the relying party

[Paul E. Jones]

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
<http://www.pomcor.com/whitepapers/PKAuth.pdf> .

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 <http://www.pomcor.com/whitepapers/PKAuth.pdf>  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/20110114/04e67319/attachment.html>