[OpenID] What's broken in OpenID 2.0? (IIW session)

[Allen Tom]

Hi OpenID community,

I'd like to address the following issues at next week's IIW session:

1) OpenID realm spoofing 
2) OpenID recycling
3) Shared secrets in the clear

Issue #1) OpenID realm spoofing - This issue was first raised on the
security list in February.
http://openid.net/pipermail/security/2007-February/000241.html

The ability of a phishing site to spoof the realm using an open redirect
server or by exploiting an XSS flaw on a trusted domain means that
neither the user nor the OP knows what site that the user is signing
into. This leaves users vulnerable to being phished on the RP site
because OPs, including AOL and MyOpenID, use the realm and return_to
parameters to assert the identity of the RP to the user before
redirecting the user back to the RP.

For example, it's pretty trivial for a phishing site to get the AOL or
MyOpenID OPs to tell the user that they're signing into *.aol.com,
*.microsoft.com, or *.go.com by exploiting redirect servers or XSS flaws
on these trusted domains.

An attack scenario would be for a phisher to send an email to a user
claiming to be from the billing department of their ISP telling the user
to update their billing information by clicking on a link. The link
would generate an Auth Request to the OP with the following parameters:

realm=*.isp.com
return_to=<isp.com's redirect server>/<url of phishing site>

Since the user's OP tells the user that they're signing into isp.com,
the user may be willing to enter their credit card information on the
destination page which is actually the phishing site. 

Because the realm can be spoofed, AX and SREG are completely broken and
are very dangerous if non-trivial data is sent to the RP. 

The realm can be spoofed by using an open redirect server on a trusted
domain as illustrated using the x.go.com redirect server in the posting
to the security list in February, or by using open Reverse Proxies or
XSS flaws on the trusted domain. 

Redirect servers, open reverse proxies, XSS flaws, and the like are
widely known and eagerly circulated within certain communities, and
without a doubt these bozos would be cranking out millions of SPIMs and
SPAMS every hour if OpenID were to gain any traction in the mainstream.
But it only takes one or two widely publicized incidents before OpenID
becomes synonymous with phishing and weak/no security.

If OpenID is to used for anything more signifcant than posting blog
comments, then this issue absolutely must be solved in the OpenID 2.0 spec.

One possible solution would be to define a way for an OP to discover an
RP's realm and valid return_to urls, perhaps by publishing this data in
a known location that the OP can verify before servicing an Auth
Request. For example, if the return_to was http://host.rp.com/return_to,
the OP could request http://host.rp.com/openid.txt which would indicate
that host.rp.com/return_to was a valid return_to for that host.
Obviously, OPs would not follow redirects when requesting openid.txt.
This file could also contain other relevant information about the OpenID
implementation on host.rp.com. OPs can cache this file without
requesting it on every auth request to optimize the user experience. If
the OP could not verify the realm (for example, if the RP is behind a
firewall) then the OP could strongly warn the user before servicing the
Auth Request.


Issue #2) OpenID recycling

In order to free up desirable userids, many large OPs recycle userids
belonging to inactive accounts. If an OpenID is recycled, the new owner
will be able to access the previous owner's data if the RP is not aware
that the OpenID has changed ownership. 

This is a very problematic issue for mainstream OPs. For example, if
someone (unknowningly) uses a recycled OpenID to sign into Zooomr, the
user may see the previous owner's private photos.  If this is not
already obvious, this scenario could be potentially very disturbing to
both the previous and the new owner of the OpenID, as well as for Zooomr
and the OP. In this example, it will only take a few well publicized
incidents before OpenID is labled as dangerous and insecure by the
mainstream media. Another interesting example would be if billing and
credit card information at an online merchant was leaked because an
OpenID changed ownership.

As with issue #1, the OpenID recycling issue must be resolved if OpenID
is to be used for non-trivial uses, as non-trivial RPs and OPs are
legally and ethically held accountable to properly safeguard user data.
One potential solution would be for the Authentication Response to
contain a nonce (or creation timestamp) for the OpenID that is reset
when the OpenID changes ownership. RPs should use both the OpenID url
and the nonce to identify users. Returning a nonce in the Auth Response
would not protect against the situation where both the OpenID and the OP
changes ownership, because obviously, the new owner of the OP can hack
their OP to return any nonce or timestamp, but returning a nonce may be
sufficent to satisify legal requirements for large OPs that recycle
OpenIDs. 


Issue #3) Returning Shared Secrets in the clear

If it is not possible to transmit a shared secret using HTTPS, why even
bother with Diffie-Hellman key exchange, or even worse, why return the
shared secret in the clear? If an RP is unable make an association
request using HTTPS, then it should be required to directly verify
incoming assertions with the OP. The OpenID protocol could be simplified
and be made more secure by dropping support for association via HTTP. 

Additionally, the OpenID spec should be reworded to encourage RPs to use
stateless mode, as in practice, securely storing shared secrets,
properly calculating and verifing signatures, and implementing a cache
of used nonces, is actaully pretty hard to get right, and incorrect
implementations are security holes.


I look forward to discussing these issues and more next week at IIW.

Allen