18

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.
Chris W. Rea
  • 1,156
  • 1
  • 12
  • 18
David
  • 181
  • 1
  • 3

6 Answers6

7

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 *.livejournal.com 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.

sysadmin1138
  • 131,083
  • 18
  • 173
  • 296
  • 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
  • After reading this I found myself on openid.net, and the first thing I saw was the headline "The Foundation of Internet Identity" on a backdrop of a stock photo of three hands playing Jenga -- each picking a piece from a very unstable-looking tower. – Andreas Oct 21 '17 at 01:56
2

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.

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • 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
  • 2
    @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
1

David, your assumption is false. OpenID works like this: 1) You want to log in to site relyingparty.com 2) You give relyingparty.com your OpenID, e.g. david.com 3) relyingparty.com checks david.com (hey, it's a URL) for a so called OpenID endpoint which can be found at david.com but through means of delegation also somewhere else, e.g. yahoo.com or google.com. let's call it davidsopenidprovider.com 4) You're redirected to davidsopenidprovider.com now. davidsopenidprovider.com's job is to authenticate you. You have to log in to davidsopenidprovider.com. It is up to davidsopenidprovider.com 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 davidsopenidprovider.com how it handles authentication. Then It asks if you really want to log in to relyingparty.com. 5) If you successfully logged in to davidsopenidprovider.com you will be redirected back to relyingparty.com and automatically logged in there. 6) davidsopenidprovider.com only assures relyingparty.com 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 any-site.com, 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 any-site.com. 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.

0

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 http://ceejayoz.com/, but my OP is WordPress.com. Two META tags in the head of http://ceejayoz.com/ allow me to do this, and I can change it anytime I like.

ceejayoz
  • 32,469
  • 7
  • 81
  • 105
0

Your openID is your provider. pwnguin.net is my openID. This is not subject to guessing, it's simply a known fact. What protects my openID is the software running on pwnguin.net, 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.

jldugger
  • 14,122
  • 19
  • 73
  • 129
0

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 any-site.com, 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 serverfault.com to know the ID I use to login to Etrade.com. 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.

  • I know this old but, knowing the openid "id" is useless...google 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