On 4/29/09 4:17 AM, Blaine Cook wrote:
> What if, in the case of "Login with Twitter", the "identity" of the
> user logging in is a random cookie string?
As long as it's random every time - i.e., a nonce.
> We're not going to solve verifiable identity federation here.
I wouldn't dare even try. :-)
> What we need right now is a careful vulnerability assessment of the
> verification key ("signed callback") approach. It seems like we have
> by far the most consensus around that approach, and it is relatively
> simple to implement for both consumer and service provider alike. If
> anyone has any ways that the two proposals on the table*do not* solve
> the security problem that we face*right now*, then please raise them!
The signed callback approach only closes the security problem we face
*right now* if and only if ALL consumers maintain perfect secrecy of the
consumer key and secret and and secret. If SP allows even one consumer
to use OAuth to gain access to its resources and the consumer is
compromised, the signed callback approach does NOT close the security
problem.
--
Dossy Shiobara | [email protected] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
