No, my point is that exposing the access token (which is more powerful) by default is a poor idea.
On Thu, May 20, 2010 at 10:07 AM, Breno de Medeiros <[email protected]>wrote: > Yes, that's my point. > > David's point is that we need two tokens to defend against these scenarios. > > On Thu, May 20, 2010 at 10:02, Allen Tom <[email protected]> wrote: > > Isn't this currently the case with the OpenID/Oauth Hybrid? If the RP has > an > > Access Token for the user, and the RP's login cookies are compromised, > the > > attacker will be able to use the RP as a proxy to the user's data on the > OP. > > > > Is there a new attack scenario that has been introduced that was not > already > > present in the existing OpenID 2.0/Hybrid? > > > > Allen > > > > > > On 5/19/10 11:06 PM, "Breno de Medeiros" <[email protected]> wrote: > > > >> I am saying that if someone steals the user login cookie for > >> coolcalendar.com and coolcalendar also has a token to access the user > >> contact data, it's pretty likely that the attacker will recover the > >> contacts even if the login cookie is not the same token as the contact > >> access token. > >> > >> It is probably more effective as a security mechanism to restrict > >> lifetime of access token in this case. > >> > >> On Wednesday, May 19, 2010, Allen Tom <[email protected]> wrote: > >>> Hi Breno, > >>> > >>> Can you describe the attack scenario with an example? > >>> > >>> Thanks, > >>> Allen > >>> > >>> > >>> > >>> On 5/19/10 8:38 PM, "Breno de Medeiros" <[email protected]> wrote: > >>> > >>>> On Wed, May 19, 2010 at 20:36, David Recordon <[email protected]> > wrote: > >>>>> So because one thing is potentially insecure we should knowingly make > two > >>>>> things insecure? I'm not following your logic here. :-\ > >>>> > >>>> I am saying that the first insecure thing unlocks the second. > >>>> > >>>>> > >>>>> On Wed, May 19, 2010 at 8:34 PM, Breno de Medeiros <[email protected] > > > >>>>> wrote: > >>>>>> > >>>>>> On Wed, May 19, 2010 at 20:28, David Recordon <[email protected]> > wrote: > >>>>>>> And given that the server would return one token good for both the > >>>>>>> `openid` > >>>>>>> and `calendar` scopes, leaking it via HTTP cookies would be bad. > Thus in > >>>>>>> my > >>>>>>> proposal the access token remains secret and is useful for a > variety of > >>>>>>> scopes while the signature sure another form of a "token" can > become > >>>>>>> public and not compromise security. > >>>>>> > >>>>>> Isn't it likely that compromising the logged-in state at the client > >>>>>> exposes the data protected by the access token anyway, since the > >>>>>> client has access to the token and therefore the data was probably > >>>>>> imported and is available in the client? > >>>>>> > >>>>>>> --David > >>>>>>> > >>>>>>> On Wed, May 19, 2010 at 8:18 PM, Allen Tom <[email protected]> > wrote: > >>>>>>>> > >>>>>>>> Whoa, I think it¹s premature to say that Yahoo supports OpenID > Connect, > >>>>>>>> but I would imagine that only a single Access Token would be > returned > >>>>>>>> to > >>>>>>>> coolcalendar.com the Access Token would presumably be good for > both > >>>>>>>> ³openid² and ³calendar² scope. Why would the OP want to return 2 > >>>>>>>> tokens? > >>>>>>>> > >>>>>>>> Allen > >>>>>>>> > >>>>>>>> > >>>>>>>> On 5/19/10 5:27 PM, "Dirk Balfanz" <[email protected]> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> Let's say I'm coolcalendar.com <http://coolcalendar.com> , and I > want > >>>>>>>> to > >>>>>>>> "connect" one of my user's accounts to his Yahoo! account. I don't > want > >>>>>>>> to > >>>>>>>> roll my own auth system, so I'm happy to see that Yahoo! supports > >>>>>>>> OpenID > >>>>>>>> Connect. To connect, I'll send the user over to Yahoo! with > >>>>>>>> scope=openid%20yahoo-calendar. What I get back, in your proposal, > is > >>>>>>>> two > >>>>>>>> different kinds of "tokens": the access token that my servers use > to > >>>>>>>> access > >>>>>>>> Yahoo! and something I'll call "openid connect token" (which in > your > >>>>>>>> proposal comprises a few different parameters - user id, > timestamp, > >>>>>>>> signature, etc.) that browsers use (in form of a cookie) to access > my > >>>>>>>> own > >>>>>>>> servers at coolcalendar.com <http://coolcalendar.com> . > >>>>>>>> > >>>>>>>> Why do those two tokens look different? They serve the same > purpose - > >>>>>>>> authenticating access from a client to a server, so they should > look > >>>>>>>> the > >>>>>>>> same. > >>>>>>>> > >>>>>>>> Why should Yahoo! run different code to authenticate requests > coming > >>>>>>>> from > >>>>>>>> my server than the code I'm running on my servers to authenticate > >>>>>>>> requests > >>>>>>>> coming from browsers - we have to solve the same task, so we > should run > >>>>>>>> the > >>>>>>>> same code. It's simpler. > >>>>> > > > > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
