OpenID at risk due to DNS flaw, warns researcher

OpenID at risk due to DNS flaw, warns researcher

Summary: The reliance of OpenID on the Domain Name System puts the integrity of the authentication system at risk, a Sun technologist has warned

SHARE:
TOPICS: Security
1

A fundamental issue affects the OpenID authentication system, due to its reliance on the Domain Name System, a Sun identity-technology specialist has warned.

Robin Wilton, a corporate architect for federated identity at Sun, described OpenID's reliance on the integrity of the Domain Name System (DNS) as a "multi-factor problem" in light of the discovery of a fundamental flaw in DNS by security researcher Dan Kaminsky.

"You may have seen the recent announcements about DNS cache poisoning, and the potential effect of this on all kinds of internet-based applications' security," Wilton wrote in a blog post on Friday. "One area in which it can have a particularly significant impact is OpenID."

OpenID is a shared, online identity service that lets people create one single login to use on multiple sites. Its supporters include major organisations such as Microsoft, Yahoo and the BBC.

Wilton wrote that OpenID is not designed to require the prior exchange of security information between parties for the process to work. Instead, it relies on the integrity of the underlying DNS system to ensure that identity is vouched for by the "correct" trust provider. This means that, if the underlying DNS system is compromised (for example, through cache poisoning), authentication is undermined, as it is impossible to tell whether an entity vouching for an identity can be trusted.

Wilton wrote that none of Sun's enterprise authentication systems had been affected as it uses the Liberty authentication mechanism, a rival to OpenID. Sun had been investigating OpenID as a research project, he said.

Another problem with OpenID was highlighted in a security advisory published on Friday, which quoted findings by Google researcher Ben Laurie, and Richard Clayton, of the Cambridge University Computer Labs. Various OpenID providers have TLS server certificates that use weak private keys, the researchers said, as a result of a previously reported flaw in the Debian random-number generator. This opens the door to a cache-poisoning attack where a malicious server would pretend to be the true OpenID provider.

Writing in a blog post on Saturday, Clayton said that this flaw particularly affected Sun's implementations of OpenID.

"The problem that Ben and I have identified is that an attacker can poison a DNS cache so it serves up the wrong IP address for openid.sun.com," Clayton wrote. "Then, even if the victim is really cautious and uses HTTPS and checks the cert, their credentials can be phished. Thereafter, anyone who trusts Sun as an [OpenID] identity provider could be very disappointed."

Topic: Security

Tom Espiner

About Tom Espiner

Tom is a technology reporter for ZDNet.com. He covers the security beat, writing about everything from hacking and cybercrime to threats and mitigation. He also focuses on open source and emerging technologies, all the while trying to cut through greenwash.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

1 comment
Log in or register to join the discussion
  • Mitigating the fallout

    While there is certainly a non-vanishing risk of some phisher posing as openid.sun.com, we have taken certain steps to make sure that our users are reasonably protected: the weak Debian-generated certificate has been replaced and revoked, and most modern browsers can check the status of certificates using OCSP (all Firefox, on by default in Firefox 3.x; IE 7 and later on Vista). In addition, we published a list of best practices for safer browsing at http://blog.beuchelt.org/2008/08/07/Some+Security+Advice+For+Our+OpenID+Users.aspx
    and internally.

    Going forward, we are working to migrate our OpenID service to use HTTPS-based OpenIDs exclusively. There are some obvious issues, since http://some.open.id is not the same user as https://some.open.id.

    At the end of the day, the OpenID service is a research experiment. Users have been warned that the service should under no circumstances be used for transactions that require any degree of assurance. We are trying to evaluate the operational characteristics of a 'user-centric' IdP.

    For a number of reasons, we can so far not recommend OpenID based services for authentication of any high-value transactions. Microsoft and some other have attempted to combine OpenID with the somewhat better security of the Information Card system, but these are changing the underlying protocols in such a way, that most of it "OpenID-ness" is benig replaced by the WS-* protocol suite of the Information Card model. Other attempts to increase the security of OpenID (such as the PAPE extensions or browser supported authentication) can help to address some of the security issues, but a number of vectors to attack the system remain wide open.

    Regards,

    Gerald Beuchelt
    beuchelt