tags:

views:

94

answers:

3

When authenticating to any site (including stackoverflow) with an AOL OpenID, it appears that you can specify any fake username in the form, then enter a valid AOL username/password on the AOL OpenID site, and the target web site (e.g. stackoverflow) will be told that authentication succeeded, but with the FAKE username.

My question is, is this the way OpenID is supposed to work, or is AOL doing something wrong, or am I just misunderstanding what's going on?

I came across this on my own project, and after hours of debugging, decided to see if I could reproduce it on a well established site.

I went to stackoverflow, clicked "log in", clicked the AOL logo, and entered "asdf" as the username. It took me to the AOL OpenID site, where I entered my true AOL username/password. I was then returned to stackoverflow, which said:

Confirm OpenID
This OpenID does not have an account on Stack Overflow yet:
http://openid.aol.com/asdf
Create New Account

I clicked "Create" and there's now an "http://openid.aol.com/asdf" account on stackoverflow (sorry! I tried to delete it but don't see how).

This doesn't seem right... and in my app, it means that the identifier I'm using for my users may not be accurate/valid... it might even be possible for someone unscrupulous to come along, enter someone elses AOL OpenID username/URL into a login box, authenticate with a valid AOL username/password, and then gain access to the other account on the target web site?

On OpenID provider sites that return a unique identifier, like Google or Yahoo, this doesn't seem to be an issue.

Thanks for any suggestions... this is driving me crazy on my development effort...

+2  A: 

An OpenID relying party (stackoverflow) is supposed to perform discovery on the ID you give it (asdf) in order to find the OpenID provider (AOL). Then, when you have logged in to the provider and it sends back a positive ID assertion, the relying party is supposed to verify that the claimed ID in the assertion matches the earlier-discovered information. This is how OpenID prevents spoofing. If stackoverflow is using the originally-entered ID instead of the ID in the final assertion without verifying a match, that would be a bug.

(I'm over-simplifying a little, but that's the gist of it. Read the spec for details, particularly on delegation and the difference between a claimed ID and a local ID.)

Here is a site that will test this verification:

http://www.test-id.net/RP/VerifyAssertionDiscovery.aspx

Here are more tests:

http://www.test-id.net/

Also, the provider is allowed to assert that any ID in its own realm belongs to you, as long as it never asserts that the same ID belongs to someone else. This allows a provider to generate (on your behalf) a different ID for each relying party you visit, so you can't be tracked across multiple sites using the same ID. It's a privacy feature (though I don't know if any providers implement it yet).

Forest
Thanks. I still wonder if AOL is doing something wrong...What I see coming back from AOL in the OpenID response is: @canonical_id=nil, @claimed_id="http://openid.aol.com/asdf", @display_identifier=nil, @local_id=nil, @server_url="https://api.screenname.aol.com/auth/openidServer", @identity_url="http://openid.aol.com/asdf"Since AOL is returning "asdf" for both the claimed_id and identity_url, even though I authenticated at AOL with a different username, are they broken?
MikeF
Some of those fields are unfamiliar to me. For example, although identity_url sounds like a concept in OpenID, it is not one of the fields mentioned in the spec. Also, I have no idea what those @ signs are supposed to be. Perhaps AOL is doing something proprietary? Regardless, it doesn't necessarily mean it's letting you spoof anyone; it could just be assuming that you want to use the asdf ID as an alternate to your own (assuming that ID is not already in use by someone else).
Forest
Apologies - the @ signs are part of the output from the Ruby gem parsing the OpenID response. When I look at the actual HTTP url response, there are no @ signs, but the rest of the info is the same. I think some of the fields (identity_url) are passed by the application making the request, and then echoed back in the response. As far as spoofing vs. allowing use of an alternate ID, I just tried using a known good AOL screen name (e.g. already in use) as the claimed_id, but authenticated with my other screen name/password, and it succeeded (allowed auth, even though the screen name was not mine
MikeF
I don't see identity_url anywhere when I log in to stackoverflow, so I'm thinking the weird fields are either your ruby code or AOL. I don't know what more to tell you. The OpenID protocol does protect against spoofing, and I don't see any evidence of stackoverflow breaking that protection. If something is broken, it's probably your code or AOL. I suggest making liberal use of the test site I linked above (it tests providers and relying parties), reading the OpenID spec, and making sure your code follows the rules.
Forest
OK thanks. The fact that I can make arbitrary stackoverflow accounts with OpenID urls that don't belong to me tells me something's not right (removing my own development skills from the equation). I'll do some more investigation and see if I can track down anything else on AOL's side...... unfortunately I can't seem to get the test sites you listed to work with AOL. When I enter my valid AOL OpenID Identifier and click "Begin", it immediately says "Login failed: No OpenID endpoint found". I'll keep researching -- thanks for the pointers...
MikeF
Good luck. Also, before calling foul, make sure AOL isn't doing something very clever like dynamically accepting the made-up ID and associating it with your account when you log in. That would be legal, as long as someone else didn't already have the ID.
Forest
Confirmed... I just used a known-good AOL screen name (a friend's) as my "fake" ID (the one I entered in the stackoverflow "AOL screen name" input field), and then on the AOL OpenId page I authenticated with my own screen name/password, but my friend's screen name was returned to stackoverflow which created the stackoverflow account with my friend's screen name.
MikeF
I've run through my test again and posted screenshots at http://mfischer.com/openid-test/
MikeF
Interesting. Now the question becomes: are you sure AOL returned an assertion for your friend's OpenID, or did it correctly return your OpenID and Stack Overflow ignore it in favor of the one you first entered?
Forest
My OpenID doesn't appear anywhere in the AOL response. Don't think stackoverflow's at fault. Will reach out to some AOL contacts I know to find out more.
MikeF
Out of curiosity, is your friend stevecase still able to use the openid that you took over from him?
Forest
+1  A: 

This would be a (extremely serious) bug in the AOL OpenID Provider. However, I just tried them and it didn't work for me. Maybe they fixed it. Can you try again?

Andrew Arnott
Just tried again 5 mintues ago, same result. Try going to stackoverflow in a different browser (one that doesn't have a stored login cookie)... try to log in, click "AOL", and enter an AOL screen name that isn't yours. When you get to the AOL OpenID site, you'll need to change the screen name in the input field (either with a browser plugin that allows editing readonly form fields, or with something like lastpass). Change it to your valid AOL screen name, enter password, and you'll be authenticated... but stackoverflow will create an account with the "fake" screen name you originally entered.
MikeF
I've run through my test again and posted screenshots at http://mfischer.com/openid-test/
MikeF
All I can get is "canceled" as the response from AOL after I try to finish logging in. The screenshots seem helpful... I just can't repro them. Does AOL ask you whether to give up your email address when logging into StackOverflow in this repro? What do you do on that screen?
Andrew Arnott
Ah, I finally got a repro. I don't know if I did anything unique this time around. Thanks for the report! I'm working with AOL to get that fixed.
Andrew Arnott
+1  A: 

Hi Mike, Can you please try your test again? I believe the issue is resolved.

George Fletcher
It's resolved! Thanks George... long time no see!
MikeF