Is OpenID this easy to hack or am I missing something?
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
- Enter their own OP address.
- Have it validate them as owning your OpenID.
- 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...
- How do you know they do?
- You could never change your OP without also changing your OpenID.
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.
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.
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.