IRC Log for #openid on 2010-05-21

Timestamps are in UTC.

  1. [00:52:26] * oxi (~oxi@unaffiliated/oxi) Quit (Quit: oxi)
  2. [01:04:18] * brandondb (~brandondb@ool-44c22f6f.dyn.optonline.net) has joined #openid
  3. [01:04:49] <brandondb> hello, is this a good place to ask an open id implementation question?
  4. [01:07:44] * brandondb (~brandondb@ool-44c22f6f.dyn.optonline.net) has left #openid
  5. [01:08:39] * brandondb (~brandondb@ool-44c22f6f.dyn.optonline.net) has joined #openid
  6. [01:10:29] <flaccid> sure
  7. [01:11:13] <brandondb> thanks -- I'm trying to implement openid for integrating with the Google Apps Marketplace
  8. [01:11:37] <brandondb> I spotted this code in the Facebook Tornado server: http://github.com/facebook/tornado/blob/master/tornado/auth.py
  9. [01:12:06] <brandondb> the interesting bit is that the relying party redirects to google, then google redirects back to the relying party
  10. [01:12:17] <brandondb> but I don't see any checking of the signature or anything
  11. [01:13:26] <brandondb> so my question is: what do I need to do to verify the request is real? it seems like this code, and other documentation I have read are vulnerable to replay attacks
  12. [01:13:50] <brandondb> and other spoofing
  13. [01:14:34] <brandondb> http://code.google.com/apis/accounts/docs/OpenID.html for example, doesn't talk about validating the response
  14. [01:15:26] * daleolds (~daleolds@137.65.156.30) has left #openid
  15. [01:21:55] <flaccid> the response is signed
  16. [01:22:12] <brandondb> but with what key?
  17. [01:22:55] <flaccid> openid.sig and openid.assoc_handle for the association plus the dated openid.response_nonce
  18. [01:24:30] <brandondb> so is there a symmetric or asymmetric key?
  19. [01:24:49] <flaccid> did you look at the spec?
  20. [01:25:11] <brandondb> i did, but honestly I'm having a hard time reconciling the spec with practice
  21. [01:25:35] <flaccid> yeah
  22. [01:25:48] <flaccid> you could checkout one of the libraries and examples
  23. [01:25:58] <brandondb> I've been reading the source to python-openid as well
  24. [01:26:28] <brandondb> but it seems a bit more complicated than I need, considering I only want to support Google Apps accounts
  25. [01:26:41] <flaccid> i've never done any google apps stuff..
  26. [01:26:57] <brandondb> well i figured that's exactly 1 "association"
  27. [01:27:11] <brandondb> so I should be able to get their public key and then use that to verify the signature
  28. [01:30:01] <flaccid> i got no idea of the flow sorry..
  29. [01:30:07] <flaccid> not for google apps
  30. [01:30:13] <brandondb> ok thanks
  31. [01:30:32] <brandondb> I'm looking at the spec now
  32. [01:30:56] <flaccid> google further complicates things and irc forks openid/oauth in some ways
  33. [01:31:07] <flaccid> so yeah i would expect research and learning will be required
  34. [01:31:12] <brandondb> yeah, they are doing some crazy voodoo
  35. [01:31:18] <brandondb> I've been banging my head against this for 2 days now
  36. [01:31:19] <flaccid> unless someone else he can jump in to help out
  37. [01:31:31] <flaccid> yeah don worry i banged myself on openid for weeks
  38. [01:31:44] <flaccid> but creating an OP and RP with a lib is a good way to learn
  39. [01:31:48] <flaccid> against the spec..
  40. [01:32:00] <yangman> google's OID isn't too crazy
  41. [01:32:14] <brandondb> hi yangman
  42. [01:33:05] <brandondb> I can craft a redirect URL to google, and after logging in, am redirected back to my site
  43. [01:33:26] <yangman> yeah. you verify it using that's in the URL
  44. [01:33:27] <brandondb> but I do not know how to verify the the authenticated login request
  45. [01:33:35] <brandondb> huh?
  46. [01:33:45] <yangman> *what's in the URL
  47. [01:33:46] <flaccid> in the libs there is a method for that..
  48. [01:34:11] <yangman> there is no key based signing
  49. [01:34:27] <brandondb> right, but we need a shared secret or something right? otherwise people can spoof that, right?
  50. [01:34:42] <yangman> there's enough uniquely identifiable information in the redirect URLs themselves to prevent spoofing
  51. [01:34:58] <yangman> any secret is between the User and OP
  52. [01:35:02] <yangman> the relying party does not get involved
  53. [01:35:38] <yangman> what the RP verifies is that the final redirect is valid
  54. [01:35:50] <brandondb> hmmm ok im not sure how that works though. here's why:
  55. [01:35:54] <brandondb> you go to example.com/login
  56. [01:35:56] <yangman> it can inject whatever it needs into the final redirect URL to identify uniqueness internally
  57. [01:36:01] <brandondb> get redirected to google.com/whatever
  58. [01:36:16] <brandondb> the user logs in there and gets redireted to example.com/login2
  59. [01:36:53] <brandondb> what is stopping a random user from going to example.com/login2?openid.claimed_id=https://www.google.com/blahblah
  60. [01:36:59] <brandondb> and stealing a random user's identity?
  61. [01:37:11] <brandondb> that's the part i don't get
  62. [01:37:16] <flaccid> the fields i mentioned before... mainly the association
  63. [01:37:40] <brandondb> assoc_handle ?
  64. [01:38:03] <brandondb> so that is unique between example.com <--> google.com ?
  65. [01:38:13] <flaccid> well thats what an association would be..
  66. [01:38:19] <brandondb> right, that's what i thought
  67. [01:38:29] <brandondb> but then couldn't i just copy the assoc handle from another request?
  68. [01:38:33] <brandondb> i can just copy paste that
  69. [01:38:38] <brandondb> it's not cryptographically secure
  70. [01:38:41] <yangman> sorry, yeah, there's a step where RP and OP establishes a shared secret
  71. [01:38:50] <brandondb> ok, right, that's what i thought
  72. [01:38:51] <flaccid> its not just the assoc
  73. [01:39:10] <brandondb> so that shared secret is in the openid.sig param somehow?
  74. [01:39:41] <brandondb> base64(HMAC(secret(assoc_handle), token_contents)
  75. [01:39:45] <brandondb> is what I see in the spec
  76. [01:40:33] <brandondb> although i'm not entirely sure what "secret(assoc_handle)" means... is that some function of the assoc handle and the secret or is that more like secrets[OP]
  77. [01:40:44] <yangman> gtg. will be back in a few hours if you still need help
  78. [01:41:00] <brandondb> thanks!
  79. [02:03:50] * jdk2588_ is now known as jdk2588
  80. [02:05:19] * jdk2588 (~jdk2588@117.199.113.33) Quit (Remote host closed the connection)
  81. [02:07:48] * jdk2588_ (~jdk2588@117.199.113.33) has joined #openid
  82. [02:11:50] * jdk2588_ is now known as jdk2588
  83. [02:12:04] * jdk2588 (~jdk2588@117.199.113.33) Quit (Changing host)
  84. [02:12:04] * jdk2588 (~jdk2588@unaffiliated/jdk2588) has joined #openid
  85. [02:15:52] * karstensrage (~karstensr@c-71-202-243-186.hsd1.ca.comcast.net) has joined #openid
  86. [02:55:04] <brandondb> ok so I finally figured it out!
  87. [02:55:32] <brandondb> there is no shared secret in stateless mode
  88. [02:55:59] <brandondb> After the client redirects to you, you can do an additional query to the open id endpoint, but change openid.mode=check_authentication
  89. [02:56:20] <brandondb> check_authentication will let the provider verify the nonce and signature for you!
  90. [02:57:15] <brandondb> It's actually covered in http://wiki.openid.net/Introduction but I read that 2 days ago and simply couldn't wrap my head around it until now
  91. [02:57:25] <brandondb> thanks flaccid and yangman for your help
  92. [02:57:58] <brandondb> but whew, I really think that the openid ecosystem is a bit of a cluster fuck of unnecessary complexity =-O
  93. [02:58:01] <brandondb> thanks again, cheers
  94. [02:59:49] <flaccid> nps
  95. [03:00:04] <flaccid> if you want something to be secure, chances are you will need crypto
  96. [03:00:13] <flaccid> which is never simple
  97. [03:07:37] <brandondb> well that's the thing: you *don't* need crypto in this case :-)
  98. [03:07:38] <brandondb> I thought I did
  99. [03:08:47] <flaccid> um thats what openid uses
  100. [03:41:34] * jdk2588 (~jdk2588@unaffiliated/jdk2588) Quit (Ping timeout: 240 seconds)
  101. [04:00:06] * brandondb (~brandondb@ool-44c22f6f.dyn.optonline.net) Quit (Quit: brandondb)
  102. [06:40:32] * MacTed (~Thud@c-24-61-62-241.hsd1.ma.comcast.net) has joined #openid
  103. [07:12:27] * tbbrown (~tbbrown@tx-71-52-73-250.dhcp.embarqhsd.net) has joined #openid
  104. [07:20:32] * xpo (~xpo@bearstech/xpo) Quit (Quit: xpo)
  105. [08:17:27] * xpo (~xpo@bearstech/xpo) has joined #openid
  106. [09:02:44] * xpo (~xpo@bearstech/xpo) Quit (Ping timeout: 264 seconds)
  107. [09:20:48] * xpo (~xpo@bearstech/xpo) has joined #openid
  108. [09:36:24] * xpo (~xpo@bearstech/xpo) Quit (Ping timeout: 240 seconds)
  109. [09:53:37] * kengyu (~kengyu@210.242.151.101) Quit (Ping timeout: 248 seconds)
  110. [11:05:17] * ponchopilate (~markthomp@host81-149-182-71.in-addr.btopenworld.com) has joined #openid
  111. [11:07:18] * ponchopilate (~markthomp@host81-149-182-71.in-addr.btopenworld.com) Quit (Client Quit)
  112. [11:14:12] * xpo (~xpo@bearstech/xpo) has joined #openid
  113. [14:01:52] * tbbrown (~tbbrown@tx-71-52-73-250.dhcp.embarqhsd.net) Quit (Ping timeout: 240 seconds)
  114. [14:28:02] * karstensrage (~karstensr@c-71-202-243-186.hsd1.ca.comcast.net) Quit (Quit: Leaving)
  115. [15:09:48] * jdk2588 (~jdk2588@117.199.120.148) has joined #openid
  116. [15:54:52] * daleolds (~daleolds@137.65.156.30) has joined #openid
  117. [16:31:12] * jdk2588 (~jdk2588@117.199.120.148) Quit (Ping timeout: 258 seconds)
  118. [16:53:56] * xpo (~xpo@bearstech/xpo) Quit (Quit: xpo)
  119. [17:39:00] * xpo (~xpo@bearstech/xpo) has joined #openid
  120. [17:49:11] * xpo (~xpo@bearstech/xpo) Quit (Quit: xpo)
  121. [18:00:32] * xpo (~xpo@bearstech/xpo) has joined #openid
  122. [18:12:13] * xpo (~xpo@bearstech/xpo) Quit (Quit: xpo)
  123. [18:13:17] * xpo (~xpo@bearstech/xpo) has joined #openid
  124. [20:53:16] * flaccid_ (~flaccid@ppp59-167-171-15.static.internode.on.net) has joined #openid
  125. [20:53:17] * flaccid_ (~flaccid@ppp59-167-171-15.static.internode.on.net) Quit (Changing host)
  126. [20:53:17] * flaccid_ (~flaccid@unaffiliated/flaccid) has joined #openid
  127. [20:53:30] * flaccid_ (~flaccid@unaffiliated/flaccid) Quit (Client Quit)
  128. [20:56:29] * flaccid (~flaccid@unaffiliated/flaccid) Quit (Ping timeout: 260 seconds)
  129. [23:12:53] * daleolds (~daleolds@137.65.156.30) has left #openid
  130. [23:15:01] * daleolds (~daleolds@137.65.156.30) has joined #openid
  131. [23:37:28] * daleolds (~daleolds@137.65.156.30) Quit (Ping timeout: 258 seconds)
  132. [23:38:06] * daleolds (~daleolds@137.65.156.30) has joined #openid
  133. [23:38:16] * daleolds (~daleolds@137.65.156.30) has left #openid
  134. [23:49:56] * daleolds (~daleolds@137.65.156.30) has joined #openid

These logs were automatically created by OpenIDlogbot on chat.freenode.net using a modified version of the Java IRC LogBot.