Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For those Relying Parties (RP) that allow the user to specify the OpenID Provider (OP), it seems to me than anyone that knows or guesses your OpenID could

  1. Enter their own OP address.
  2. Have it validate them as owning your OpenID.
  3. Access your account on the RP.

The RP "could" take measures to prevent this by only allowing the OpenID to validated by the original OP, but...

  1. How do you know they do?
  2. You could never change your OP without also changing your OpenID.
share|improve this question

OpenID is one of those systems where you have to trust the end-points. If the RP isn't trustworthy, then this kind of association poisoning is entirely possible. If the RP is actually trustworthy, then this kind of attack is MUCH harder. The 'work around' for not being vulnerable to this attack is to key the local security principle (on ServerFault this would be your username's representation in the back end database) with the foreign OpenID endpoint (the OpenID URL, ServerFault allows you to associate multiples of these).

You can still attack by way of a DNS poisoning attack on the RP's part, such that, say * gets redirected to an OP you've specially crafted for the attack. But that's a DNS poisoning attack, not a fault in OpenID itself. OpenID is just vulnerable to DNS poisioning.

share|improve this answer
In this case a trustworthy RP could become untrustworthy because they assume that OpenID is secure in and of itself. – David Mar 25 '10 at 16:15

I think you're confusing OpenID and the other parts of User Security. Your OP is the authentication mechanism, not your account. Here on ServerFault, you have an account. That account has no means of authentication by itself; except you point it to one or more OPs.

Wheen you try to login to your Account here as SF, it asks your OP to handle Authentication. Only that one OP (or the multiple OPs, however you have it setup) can Authenticate you for the purposes of your SF Account.

There are three parts to a typical login system (called triple "A", or just "AAA"):

  • Accounting - Keeps track of your name and information specific to the site (like posts, messages, etc)
  • Authentication - Keeps track of how to make sure it's really you (commonly a password)
  • Authorization - Keeeps track of your permissions (read or write access to various things)

You can read more about AAA systems on Wikipedia.

share|improve this answer
If I'm allowed to specify any OP each time I log in, then the malicious user could also specify any OP when trying to hack my account. Thus they specify their own OP and gain access. – David Mar 25 '10 at 16:18
No, you'd just allow them, once logged in, to add additional OpenID points for their account. SO does it this way. – ceejayoz Mar 25 '10 at 17:38
@David, when you login you aren't specifying an account and an OpenID you only specify the OpenID. That OpenID must already be connected to an account, otherwise you get the option of creating a new account (at least here on SF). – Chris S Mar 25 '10 at 18:35

David, your assumption is false. OpenID works like this: 1) You want to log in to site 2) You give your OpenID, e.g. 3) checks (hey, it's a URL) for a so called OpenID endpoint which can be found at but through means of delegation also somewhere else, e.g. or let's call it 4) You're redirected to now.'s job is to authenticate you. You have to log in to It is up to how this login works. It can be username/password, it can be information cards, browser certificates, fingerprints, smart cards, out-of-band mechanisms like call verification,... It's up to how it handles authentication. Then It asks if you really want to log in to 5) If you successfully logged in to you will be redirected back to and automatically logged in there. 6) only assures that you are who you claim you are. It doesn't send any password.

So your assumption "As a consumer, When I create an account on, I have no notion of the intelligence of the developers / site managers." is false in regards to OpenID. If there's a weak point, it's the provider but not That's the problem with traditional username/password logins now. You have to trust each site which offers logins that way and not only one, your OpenID provider.

I hope this helps understanding OpenID.

share|improve this answer

How do you know they do?

The same way you know that any old site is passing along your password to someone else - you don't. That's why you use what's likely to be a reputable company.

You could never change your OP without also changing your OpenID.

Sure you can. Look into OpenID delegation.

My OpenID is, but my OP is Two META tags in the head of allow me to do this, and I can change it anytime I like.

share|improve this answer

Your openID is your provider. is my openID. This is not subject to guessing, it's simply a known fact. What protects my openID is the software running on, which only replies in the affirmative if the visitor in question has a auth cookie.

I won't say openID is secure; there's all kinds of cross site scripting that could go on, or some mundane details I tend to ignore or get wrong.

share|improve this answer

This is what I've garnered from the replies here...

OpenID is only as secure as the parties involved and that is true of any authentication method. I realized that before I started this discussion.

The issue with OpenID, as it seems to me is two-fold...

  1. Your LoginID is no longer a secret shared only between you and the site you use it on. It is your OpenID and is known by every site you use it on, and is something easily guessable like an email address or something derived from your email address or something similar.

  2. RP's may implement OpenIP on their site without doing due diligence assuming that because they are using a widely accepted 'protocol' that it is secure. Granted, most run-of-the-mill web site developers have no true concept of how to secure a site but, if they implement their own security, at least issue #1 doesn't come into play.

As a consumer, When I create an account on, I have no notion of the intelligence of the developers / site managers. I use an ID that I don't think will be easily guessable. I don't want to know the ID I use to login to I also use a different password on every site and manage those passwords with my own scheme. It is highly unlikely that my account will be comprised unless the site operatores are total idiots.

With OpenID, everyone in the WEB knows how it works and how to attack it, should the RP not have proper measures in place.

I love open source software, but in the case of OpenID I think it opens up the possibility that there will be inferior implementations available to unsuspecting adopters.

I think this could be all solved by some signed seal of approval that assures the consumer that the site has passed an audit and is not vurnurable to hacks.

Maybe I'm just paranoid.

share|improve this answer
I know this old but, knowing the openid "id" is for example uses the exact same url for exery single user. How does knowing that help you login to stackoverflow as me (other than knowing that if you can hack my google account you can be authenticated as me, but that's no different from "forgot username/password"). – jmoreno Sep 27 '11 at 15:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.