OpenId

OpenID is an open loosely distributed single sign on protocol. It looks at why Microsoft’s single sign on has not taken off on a large scale. Concluding that no-one wants a single company storing all details, hence create a distributed single sign-on protocol.

OpenIDs take the form of URLS:

exampleuser.livejournal.com

OpenID 1.1 Protocol Summary

OpenID specifications |http://openid.net/specs.bml

The openid protocol 1.1 specification in summary.

Identify the Identify Provider associated with openid submitted by the End User.
Agree a shared key between the Consumer and Identify Provider.
Redirect the End User to the Identify Provider to authenticate themselves with a password.
End User gets redirected back to Consumer with authentication data signed by the shared key.

Dumb mode –> Consumer asks Identify Provider to return whether authentication data is valid.

Smart mode –> Consumer checks signed data with shared key

Diffie hellman http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange can optionally be used when agreeing the shared key.

Trust

OpenID does not cover the concept of trust. Anyone could create a OpenID Identify Provider, create an id and then use this to login.

Hence its important to realise that the OpenID library implementations do not cover trust. A white list should be made which is then used to validate users Identify Providers and decide whether the consumer should trust them.

OpenID Provider Server URLs

LiveJournal – http://www.livejournal.com/openid/server.bml
Vox – http://www.vox.com/services/openid/server
VeriSign – https://pip.verisignlabs.com/server
MyOpenID – http://www.myopenid.com/server

There are other options than using white/black lists. Some of the more interesting ideas floating around about the use of Reputation.

Reputation for OpenID http://www.windley.com/archives/2007/03/reputation_for_openid.shtml

Wired – Herding the mob http://www.wired.com/wired/archive/15.03/herding.html

Security Issues (On-going analysis)

Malicious End User – Denial Of Service

A Malicious End User could have a OpenId which resolves to a malicious internal network. This internal connection could be for example: a [Tarpit|http://en.wikipedia.org/wiki/Tarpit_%28networking%29]. The Consumer is stuck in the tar pit, possibly timing out due to exceeding a maximum execution time.

Using a paranoid HTTP Library can help protect against this issue.

http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib/LWPx/ParanoidAgent.pm

Secret keys passed plain text

Its optional to pass the shared key using Diffie Hellman. Hence without Diffie Hellman the key could be sniffed passing between the Consumer and the Identity Provider.

Replay attacks

Nonces|http://en.wikipedia.org/wiki/Cryptographic_nonce] are not an integral part of the OpenID protocol.

“OpenID Consumer’s SHOULD add a self-signed nonce with Consumer-local timestamp in the openid.return_to URL parameters to prevent replay attacks. Details of that are left up to the Consumer.”

Consumers can operate in dumb mode, meaning they store no state. Without storing state it is not possible to protect against replay attacks. The Consumer has no history of previous nonces. Hence it would not detect a old nonce used in a replay attack.

Nonce Passing

The nonce generated by the Consumer can cross the network 3 times in plaintext as GET parameters.

Consumer Request to Identity Provider.
Identity Provider Redirection sent to End User (telling them to redirect to the Consumer)
End User request to Consumer.

The greater the exposure of the nonce and the potential to sniff the shared key means a malicious attacker could create a fake/replay/pre-play response that the Consumer would accept.

Delegating Authentication

OpenID supports a URL delegating to a Identify Provider. The URL delegates by providing ‘links’ in the html at the URL location.

Example:

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">




<link rel="openid.delegate" href="http://exampleuser.livejournal.com/">

With a single point for delegation which is resolved without user interaction there is a risk that if this homepage is comprised the delegater could be changed to a malicious identify provider. This change could go un-noticed due to the automatic resolution.

This is a Trust issue and can be solved using whitelists and phishing protection at the Consumer.

Phishing

With the redirection from one login page to another there is a worry about phishing. How do you know you have not be redirected to some malicious signin page which steals you details rather than logging you in. URLs are an answer but a lot of people do not examine the URLS. This problem is not part of the OpenID protocol but rather a problem existing for all internet sites.

Verisign has a firefox plugin SeatBelt which attempts to detect if the OpenId site is legitimate. SeatBelt|https://pip.verisignlabs.com/seatbelt.do

Single Sign on – Break a single password = access to all accounts.

A person on average has: 18 user accounts 3.47 passwords.

So people are using the same password for multiple accounts already. Single email accounts are tied to many user accounts. Any forgotten email reminders sent to an email address from a website mean the comprise of an email account can mean access to many other user accounts is possible.

Single sign-on is a risk and it would be safer to have separate user accounts each with different passwords. This however does not fit with how people are using the internet.

Its a comprise of convenience vs security and that decision needs to be made on a per solution basis.

Security Summary

The OpenID specification has optional features which if not used decrease the security of the system.

There are also security issues that are outside the OpenID protocol.

When using OpenID its important to access the security requirements of the problem and ensure that library implementations provide these optional features.

Different OpenID libraries implement the protocol and go beyond it dealing with issues like Nonces being passed in the clear to many times. Assess the libraries support of these issues.

Work outside of the OpenID is required to deal with the issue of Trust.

Phishing remains an issue.

Openid Libraries

The currently list of libraries implementations of OpenId are available in:

C#
C++
Java
Perl
Python
Ruby
PHP
ColdFusion

Many libraries go beyond the openid protocol and add protection against replay attacks.

Yadis Protocol

Although not part of the specification OpenID can use the [Yadis|http://yadis.org/wiki/Main_Page] protocol:

The Yadis protocol enables discovery of service definitions from an http:// or https:// URL. The protocol consists of performing HTTP requests to obtain a Yadis Resource Descriptor.

This enables identify providers to be discovered through an OpenID. For our example OpenID we could look at the url: exampleuser.livejournal.com

http://exampleuser.livejournal.com