0

Okay so basically here's the Bodysnatcher OpenId Provider attack scenario.

  1. Bob's Google claimed identifier is the following, ttps://www.google.com/accounts/o8/id?id=AAtawkQvytyBNNuHpRhn36f8MLvFiJvZg8teNE

  2. Jane has some how found Bob's "current" claimed identifier.

  3. She goes off and creates here own OpenId Provider, www.jane.com/accounts/o8/id, such that when asked it will return Bob's claimed identifier.

  4. She goes to some badly coded site, www.bcs.com, that uses open id and bob has an account at.

  5. She tells www.bcs.com to use the OpenId Provider www.jane.com/accounts/o8/id.

  6. Now this is the part that I don't know about and would like to know if it's possible/realistic... www.jane.com/id some how gets www.bcs.com to believe that the claimed identifier "string" (i.e. the value that the site will ultimately see) is ttps://www.google.com/accounts/o8/id?id=AAtawkQvytyBNNuHpRhn36f8MLvFiJvZg8teNE.

Is it possible, some how, even though the host is www.jane.com?

We're working to implement OpenId and we don't want to be that "badly coded site". We're using some thirdparty .NET library that gives us the Claimed Identifier so we're not sure where or how it builds it. If it is possible that it could be faked then we're considering doing some checks that the Provider OpenId's url matches what is in the Claimed Identifier.

This also brings up the concern about whether we should take the extra step of hashing/scrambling our claimed identifiers. We think so, because Google changes its identifier based on the site that is requesting the OpenId. I mean why else would it go to the trouble of doing this if not to try and protect its members?

Thirlan
  • 712
  • 1
  • 8
  • 26

1 Answers1

0

You're essentially asking if it is possible to write an implementation of OpenID consumer that violates the specification enough to introduce security vulnerabilities. Yes, it is. You could omit the whole validation process and believe everything you're told from your user.

But with a consumer that closely follows the OpenID specification, such an attack is not possible.

Since you said that you use a .NET library, you probably use DotNetOpenAuth. It's the same library that stackoverflow uses, and you probably don't have to worry about any vulnerabilities when using it. If you're using another library, it's probably the best choice to switch to DotNetOpenAuth.

As for the reason for Google to return realm-based identifiers: it is done to protect it's users' privacy, not to increase security. Basically, this ensures that you can't link your user's account to his Google account.

Mewp
  • 4,715
  • 1
  • 21
  • 24
  • Okay that's good to know since, we are using "DotNetOpenAuth". – Thirlan Jan 28 '11 at 05:50
  • So err going back to the hashing question. Can we safely assume then that openIds we receive don't have to be treated like some sort of secret code? I mean, we're not talking about being blatantly open about it just that there's some extra effort required if we treat it as secure data. Also, I see what you mean with Google. It would certainly prevent cross-site tracking as StackOverFlow has found out. – Thirlan Jan 28 '11 at 06:01
  • Neeevermind! I saw your answer to someone else's question that was exactly this. – Thirlan Jan 28 '11 at 06:03