[OpenID] security weakness regarding authentication of the relying party

[Paul E. Jones]

Francisco,

 

I’m not entirely sure how the Janrain code works, as I’ve not really looked at it.  I’m pretty sure, though, that the OP code I wrote would complain if the “return to” URL is not a sub-domain of the specified realm.  It even checks to ensure that the scheme matches (e.g., HTTPS or HTTP must be used in both places).  So, I would assume that the example you give below would fail on my server.  Not sure, of course… there’s always opportunity for a bug ;-)

 

I do agree that HTTPS ought to be used everywhere.  There are two issues with meeting that requirement.  Some argue that these issues are weak arguments, but they are truly an impediment to getting wide adoption:

1)      TLS certificates are still more expensive than they ought to be.  We’re talking about something that can be cranked out entirely automatically and in a fraction of a second and some people believe this “work” is worth more than $100. The cheapest price I’ve seen is $13 per certificate, which is getting close to reasonable, but still too high.  The domain name cost less than the certificate!  This rip-off needs to end.

2)      Many, many web servers still do not support Server Name Indication (SNI).  So, many web sites cannot even provide proper support for TLS.  It was for this reason that I wrote my OP server code such that the only piece of software that absolutely, really should be placed behind HTTPS was the one that handles password checks and cookies for checkid_immediate.

3)      Many client libraries still do not support SNI, including those running OpenID RP code.  The stock browser on Android and other browsers do not support SNI.

 

Anyway, your statement is correct, but I think there are practical reasons why the standard did not mandate HTTPS.

 

Let’s assume we mandated use of HTTPS.  What are the other issues?  I’m still not sure what they are.  The example you gave with the return_to URL would not be accepted by my server, I believe.  I’d be willing to test that theory :)

 

Paul

 

From: Francisco Corella [mailto:fcorella at pomcor.com] 
Sent: Tuesday, January 18, 2011 2:10 PM
To: openid-general at lists.openid.net; Paul E. Jones
Cc: Karen P. Lewison
Subject: RE: [OpenID] security weakness regarding authentication of the relying party

 


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 <http://www1.cse.wustl.edu/%7Ejain/cse571-07/ftp/cafecrack/index.html>  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 <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/20110118/ee520e51/attachment.html>