Many openid enabled sites default to http identifiers, even if the openid provider supports https (such as myopenid.com).

Does this pose a threat beside the identity being exposed? The second step of the openid authentication includes a verification of the signature provided by the identity provider. But couldn't a rough identity provider just sign anything? I mean is there a step in the openid protocol that verifies the provider is valid for the entered openid?

Edit: This question is about consumers such as Stack Exchange, not identity providers. Stack Exchange only uses https for Google, and unencrypted http for all other openid providers. I know that myopenid.com does support https, but Stack Exchange does not use it. The same is true for other sides, even ones that usually take security more serious than Stack Exchange, e. g. Source Forge.

3 Answers 3


In general, there are several security issues with OpenID, but also many different scenarios for its use. So depending the threat model you may or may not want to rely on it, and users may or may not want to use it for authentication.

As you note, possible exposure of your credentials is a problem, e.g. if you choose an OpenID provider that authenticates with passwords and doesn't require https. That goes for any site that asks for a password over a connection other than https. But note that identity providers not only can use https, but could also authenticate via more secure hardware tokens or one-time passwords.

Problems with phishing are particularly challenging when the user doesn't properly use a carefully-designed user interface for authentication, which is one thing that led to the development of the client component in CardSpace.

OpenID 2.0 is a bit better than 1.0, but issues like privacy and trust remain. Alternatives include SAML (e.g. via Shibboleth) and CardSpace.

Here are some links for more info:

If you want an answer specific to Stack Exchange policies, ask on https://meta.stackexchange.com/


The most concern for OpenID from my perspective is the same as for Single Sign On solutions which is XSS attacks as your credentials can be stolen by the attacker and since they should be widely used, the impact is quite brutal


Hey, if you are concerned about the security you can always visit http://wiki.openid.net/w/page/12995230/Security and join the discussions about security measures.

As for your question, MiTM attacks could be an issue if you are in a public hotspot.

If you don't trust your identity provider don't use his service. I am currently using myopenid and I trust it enough for several of my auths. As for a rough OpenID provider authing someone over another network, no it is not possible. The site you register at stores your complete ID. So if you try X.myopenid to auth as someone registered with X.blogspot you would plainly create a new account.

  • The public hotspot is the wrong location for the scenario: The attacker tries to trick Stack Exchange into talking to a rough openid provider. But Stack Exchange thinks that it is talking to myopenid.com. Since Stack Exchange uses http ://myopenid.com instead of https ://myopenid.com, there are no SSL certificates to confirm the identity of the server that Stack Exchange sees ase myopenid.com. At least not during the first step of the authentication process. Dec 12, 2010 at 16:21
  • So, you mean hijacking the domain.(Buying it on expiration?) Dec 12, 2010 at 18:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .