[oauth] Re: This whole version business
Sorry, need to do a little copy-editing of what I wrote to clarify: > If your argument is that our currently proposed change to the > protocol breaks backwards compatibility, then say so. But saying > "rev'ing the protocol version number will necessarily [break] > backward compatibility" means the protocol was BROKEN [by] design in > the first place [and should be fixed]. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: New Flow, New Endpoints
On 5/3/09 4:06 AM, Eran Hammer-Lahav wrote:
> We seem to be spending a lot of time on the question of how providers
> supporting both flows can tell which flow is being used. If they
> simply offer a new set of 3 endpoints: request token, authorize, and
> access token, this entire problem goes away. It also removed the need
> to make the oauth_callback mandatory in the new flow, or use literal
> strings to indicate out-of-band.
/v1.0/{request,authorize,access}
/v1.1/{request,authorize,access}
Look at that. Version'ed URLs for endpoints. OMG BREAK THE WEB. :-P
--
Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---
[oauth] Re: This whole version business
On 5/1/09 5:01 PM, Eran Hammer-Lahav wrote: >> Explain how rev'ing HTTP to 1.2 would have "broke the web" ... ? > > Millions of client and server would no longer be able to interoperate > without deploying new software, servers, proxies, caches, etc. When > the client and server speaks a different protocol, they cannot > interoperate. But they*obviously* can even with the changes made to > HTTP 1.1 (reality proves this). If they changed the version to 1.2, > old clients will no longer work with new servers and the change would > have added confusion. The key here is 'added no value'. If you need > to change the wire version for an actual technical reason, do it. But > since changing the wire version break stuff, you need to have a > reason to do it. You do realize that when we rev'ed HTTP from 0.9 to 1.0 and then 1.1, the web didn't "break." It is possible to rev a protocol without breaking older clients (unless you INTEND to, such as in the case of CLOSING a security threat). If your argument is that our currently proposed change to the protocol breaks backwards compatibility, then say so. But saying "rev'ing the protocol version number will necessarily backward compatibility" means the protocol was BROKEN in design in the first place. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Vulnerable token creation in PHP OAuth library
On 4/30/09 7:34 AM, Blaine Cook wrote: > A question for the security folks here: > > Is there a way to programmatically test for the relatedness of the > token and secret? Could we perform automated security audits of OAuth > libraries, looking for (anti-)patterns of implementation? It would take more engineering effort to try and create a sufficiently clever static code analysis tool to do this than it would for a proficient security auditor to review the code by hand. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] POLL: Can an SP safely allow any Consumer to use the current 1.0 securely?
On 5/2/09 2:30 PM, John Kemp wrote: > But for 2009.1, I think it's right to stay with oauth_version=1.0, and > move on to fix the actual security issue. Fine, it really doesn't matter what the oauth_version is, anyway. Can I see a show of hands - Can an SP safely allow any Consumer to use the current OAuth 1.0 (not referring to the revised 2009.1 draft) securely? [Yes or no?] In other words: If an SP allows an arbitrary Consumer to use the OAuth 1.0 flow as-is, then the security threat continues for that SP? If this is "yes" then all SP's that switch to 2009.1 _cannot_ allow the currently known insecure OAuth 1.0 flow, so "backwards compatibility" is a non-issue. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: This whole version business
On 5/2/09 1:40 PM, Eran Hammer-Lahav wrote: > OAuth has two parts: getting an Access Token and using the Access > Token. Getting an Access Token is broken but using is not. No need to > break both and changing the wire version will do that. Breaking > perfectly secure implementations just to make you*feel* more secure > is silly. Sorry, I didn't realize that there were separate specifications for each. In my mind, the two go hand-in-hand - if you can't get a token securely, you can't use them securely either. In other words: if any attacker can get an access token, then "using them securely" has no meaning. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: This whole version business
On 5/1/09 2:29 PM, Eran Hammer-Lahav wrote: > There is a difference between what you name the specification and the > string value you put on the wire. My point is that there is no reason > to change what is transmitted on the wire. I also made the point that > not changing the wire string but changing the document version will be > more confusing. Changing both just because it helps with communication > with*people* makes no sense. Protocols are for*machines* and those > do not need a new version number. Considering that the changes being made to the OAuth specification MUST break backwards compatibility -- as implementations of the current unfixed specification are KNOWN to be insecure -- makes perfect _technical_ sense to rev the version number on the wire to signify this. Continuing to use the current, known insecure, specification is negligent at best and nefarious at worst. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: This whole version business
On 5/1/09 5:41 PM, Eran Hammer-Lahav wrote: > How about we change the current version to 0.9 because it is clearly > not a finished specification. Then we increment it for the new spec > to 1.0! > > EHL > PS. Yes, this is a joke (with joint credit to Breno) :-) Sadly, OAuth falls into the Microsoft Version trap: NEVER use a ".0" release or "always wait for Service Pack 1". So, "1.1" is a good thing - maybe folks will take it seriously, hoping the kinks have been worked out. There we go: OAuth Service Pack 1. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: This whole version business
On 5/1/09 3:06 PM, Eran Hammer-Lahav wrote: > They didn’t change the protocol version (as in ‘GET /something > HTTP/1.1’) because it added no value and would have just broke the web. Explain how rev'ing HTTP to 1.2 would have "broke the web" ... ? And similarly, how does changing oauth_version to 1.1 "break" OAuth? Can you actually outline an actual scenario where this happens? I thought the whole point of the proposed change to OAuth is to _close a security hole_. That means, requests made to or from an implementation of the previous specification are INSECURE and SHOULD NOT COMPLETE, PERIOD. Or, have I learned a different definition of "security hole" than what the OAuth community uses? -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Version Preference
On 5/1/09 4:25 AM, Blaine Cook wrote: > 3. "1.1" +1. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
On 4/30/09 7:19 AM, Blaine Cook wrote: > Looks good, with the exception of the 'oob' value – why not just say > that an empty OR absent callback parameter fulfills the same role as > 'oob'? There are also plenty of service providers that require static > configuration of the callback, and in those cases the callback > parameter would be absent when obtaining the request token. I'm guessing Eran's concern was being able to differentiate between a 1.0 consumer vs. a 1.0A consumer. Having an absent callback parameter could be either. The rationale of sending a magic string like "oob" because "we can't trust that the consumer and/or server's HTTP implementation to not be BROKEN when handling empty parameters" irks me, but I didn't feel like arguing about it. If I were king, I'd say that an empty callback parameter is required for 1.0A consumers, and absent signifies 1.0 consumers. Really, why not bump the version to 1.1? Is there real magic behind the version number? What's the point of versioning the protocol if revving it is painful? -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Vulnerable token creation in PHP OAuth library
On 4/30/09 4:21 AM, Solberg Andreas Åkre wrote: > > On 30. april2009, at 10:10, Dossy Shiobara wrote: > >>> >>> https://rnd.feide.no/content/vulnerable-token-creation-php-oauth-library >> >> Ouch! Nice find. w/ rainbow table of MD5, recovering the secret from >> the token is a matter of seconds, d'oh! :-) > > Or if you do not have a rainbow table available, you could instead take > a look at your wristwatch, or even better take the oauth_timestamp and > calculate _both_ the key _and_ the secret :) LOL, oauth_timestamp FTW. Duh! -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Vulnerable token creation in PHP OAuth library
On 4/30/09 3:50 AM, Solberg Andreas Åkre wrote: > FYI > > https://rnd.feide.no/content/vulnerable-token-creation-php-oauth-library Ouch! Nice find. w/ rainbow table of MD5, recovering the secret from the token is a matter of seconds, d'oh! :-) -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Core 1.0 Rev A, Draft 1
On 4/30/09 3:25 AM, Eran Hammer-Lahav wrote: > 2. Since this change is small, I would like to give it a short review > period before another draft. Please submit all your comments by May > 8th. Looks fine! Nicely done. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/29/09 12:25 PM, Brian Eaton wrote: > On Wed, Apr 29, 2009 at 5:58 AM, Dossy Shiobara wrote: >> 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. > > Nit: nonce is probably not the right term here, because it means > "something that is used only once". Counters are perfectly acceptable > as nonces. In this case we need something unpredictable. Thanks for the correction and clarification. I agree. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/29/09 10:05 AM, Blaine Cook wrote: > In the case of applications that are distributed to end users, this > becomes a DRM problem and not one we can solve without user education > and due signaling and out-of-band trust metrics on the service > provider's side. All it takes to solve this is to change the spec. to require the user authenticate with the SP to generate an "identity nonce" which the consumer uses to begin the OAuth flow to authorize itself with SP on behalf of the user. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
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 | do...@panoptic.com | 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 oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 8:20 PM, Nat Sakimura wrote: > Right. I think I have seen something like this on this list recently, > but the problem is in this wholesale grant model. > > Let S:=Service Provider, C:=Consumer, V:=Victim, A:=Attacker, > S:V:= User V at S, S:V:Data := Data of user V at S, C:* := any user in C. > > Then, what OAuth does right now is: > > [1] Get Permission on (Grant access on S:V:data to C:*) > > by misguiding the user as (Grant access on S:V:data to C) > > This is not pretty. It is illegal in many countries (not in U.S. though.) > > And, what you are proposing is to deny the wild card in [1] above and > make it explicit, so that it will be like: > > [2] Get Permission on (Grant access on S:V:data to C:A) > > which, I think, is a good idea. > > Under this scenario, in the last vulnerability that we encountered, > the victim will be asked to grant permission to C:A, which, he > probably would not. Actually, in my proposed scenario, C:A can only try to get S:A:Data. They can't generate a way to trick V into authorizing C:A's request for S:V:data in the first place. In my proposed change, even with the Consumer key and secret AND the request token and secret being fully disclosed to the Attacker, the attacker cannot generate a request that would let the Victim authorize the token so that the Attacker could convert it to an Access Token for the Victim's data at SP. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 1:40 PM, Brian Eaton wrote: > It's fine to limit the number of unsuccessful exchange attempts, but a > limit of one is too low. Five attempts is more reasonable. > > Limiting the number of successful exchange attempts to one makes sense. This makes sense. Perhaps the spec should be organized in this way: The SP MUST invalidate the request token after a successful exchange attempt. The SP MUST invalidate the request token after a certain number of unsuccessful exchange attempts. The number is RECOMMENDED to be between 1 and 5, as appropriate. I don't see why a SP should be prohibited from expiring a token after one unsuccessful exchange attempt. IMHO, the number should be chosen based on the SP's desired security level. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 10:41 AM, Hubert Le Van Gong wrote: > Is the reason for*discarding* this solution the fact that it's > an additional roundtrip in the flow (or put another way it's too big > a change to the current protocol)? If this _is_ indeed the case, then perhaps its time to start drafting OAuth 2.0, which would include this significant change. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 10:40 AM, Peter Keane wrote: > But the consumer will still need to communicate back to the SP that it > has some unique knowledge that it could only have been offered at the > SP authentication point. Most proposals do this with the > "verification token" -- my reasoning leads me to believe that needs to > be passed "out-of-band." I'm not sure that moving the authentication > before request token necessarilly guarantees that. It doens't need to be passed out of band. You only need to defend against it being intercepted by an attacker. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 9:27 AM, Peter Keane wrote: > As an analogy, imagine if banks allowed withdrawals w/o a user typing > a PIN. The bank can guarantee that I am the one who was issued the > card AND it can guarantee that is the same card being used to withdraw > money. And you can do all kinds of things to guard against anyone but > the legitimate card owner to get ahold of it. But unless you take > that extra step (the PIN entered at the ATM) you never create > sufficiant linkages to "verify" authenticity. That's why PIN can be > short& easy to remember (but should NOT be written on the card! ;-)). > Since it is an out-of-band arrangement, it offers a high level of > assurance. Although, the banks have known for a long time that their implementation is without security. Hackers today are compromising the MDS crypto blocks and are stealing PINs en masse. Basically, the banks implemented a system that assumed that the secret would remain secret and could never be compromised, similar to OAuth's dependency on the secrets remaining secret. The banks are due for a huge overhaul of their ATM transaction platform or continue to lose serious money to the hackers. Fortunately, no one implementing OAuth has anything so valuable, yet. However, OAuth's inherent similar flaw will likely mean that no service that does have anything valuable will expose those resources using OAuth. It's a very sad, built-in limiting factor for something with such potential. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 9:05 AM, Peter Keane wrote: > That's exactly right: OAuth leverages the secrecy of the out-of-band > agreement between consumer and SP. The request token is built upon > that assumption, so it can safely be considered secret for the > purposes of OAuth. If this is the founding principle of OAuth, then perhaps I'm wasting my time. Perhaps I should instead formulate a specification for an open authorization protocol that doesn't have this assumption. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 8:41 AM, Hubert Le Van Gong wrote: > I also saw 2 additional ideas that might help > (and are not necessarily exclusive with the 2 proposals): > > (3) Make Request tokens one-time only > (4) Request that the user logs in at the Consumer before the request > token request Requiring the user authenticate to the Consumer doesn't prevent the attack, as the attacker is a legitimate user of Consumer in the attack scenario. What I keep proposing is that the user must authenticate at the _Provider_ before the request token request. This would completely eliminate the attack in the scenario. And yes, making request tokens one-time only is a MUST, IMHO. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: True OAuth Confessions, or Why My Hand-Rolled Calls All Blew Chunks
On 4/28/09 1:42 AM, Chris Messina wrote: > Is OAuth this hard for everyone else? > > http://kentbrewster.com/oauth-confessions/ > > *Sniff*. Funny enough, I ran into at least a few of the items on his list when writing my own OAuth consumer implementation from scratch. I honestly think that the OAuth _design_ isn't what makes it difficult. It's the way the specification is written. What really bit me in the ass the hardest was the "Parameter Encoding" requirement of the signature when using HTTP header authentication. Deviating from the RFC just for OAuth violates POLS, guys. Honestly, after trying to decipher the spec. and not getting very far, I put it aside and went to Eran's GUI: http://www.hueniverse.com/hueniverse/2008/10/beginners-gui-1.html I almost wish I'd not bothered to confuse myself with the spec. and just used that one page. It's a _fantastic_ reference implementation for anyone developing their own OAuth consumer. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/28/09 12:33 AM, Josh Roesslein wrote: > > Couldn't we verify the user on the consumer-side during the callback URL > redirect (user returning from SP after authorization)? > This callback URL has two pieces of data: > - Callback secrete: generated by SP after user authorizes consumer > - Request token: publicly known, so could be forged by attacker If and only if the callback URL is protected from tampering. Since we cannot guarantee the consumer secret and request token secret to be ... well, secret ... there's no way to guarantee in ALL cases that the callback URL will be protected from tampering. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Signature HMAC-SHA1 question
On 4/27/09 6:11 AM, Lee Gibbons wrote: > The OAuth spec stipulates that for HMAC-SHA1 signatures the key is the > concatentation of Consumer Secret and Token Secret seperated by&. > > Does this mean that for the initial incoming call i.e. requesting > request token, HMAC-SHA1 cannot be used for signatures because at that > point the token secret has not been supplied ? The token secret is an empty string. Proceed as normal. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
Images suck if you're blind. On 4/25/09 2:46 PM, Mike Panchenko wrote: > Pardon me if this seems naive, but if we're considering a solution in > which the user enters a pin at both ends, perhaps a better solution to > use an image instead, the way banks make show you some small thumbnail > to verify that it is indeed their site you're looking at. Perhaps the > provider could maintain a collection of such images (could easily > generate a pretty huge sample from freely license flickr photos) and > send them along with the unauthorized request token. Then at the > authorization screen, the user would simply have to pick the right image > out of a "lineup" and notified that if they have no idea what the image > is, they have been duped. It requires changes to both the consumer and > the provider and it requires that the provider maintain the image pool, > but it is certainly quite a bit better than requiring a pin at both ends. > > Once again, I'm quite the OAuth amateur, so I may be missing something > significant. Cheers, -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Moving forward
On 4/26/09 1:48 AM, Eran Hammer-Lahav wrote: > Open questions: > > 1. Am I missing a completely different alternative? If yes, please > create a new wiki page and point to it (if you don't have access ask > or email it to someone who does). Requiring SP to authenticate user _before_ the request token request, returnin an identity token to the consumer which is then required as part of the request token request. This way, an attacker can't generate a request token that can be authorized by another user. > 3. For the Signed Callback URLs solution, what to call the new > parameter returned in 6.2.3? Suggestions so far included: > > - pin - verifier - chaperon - callback token - callback secret I vote for "authorization token", which invalidates the previously issued request token and is used by the consumer to prove it has been authorized by the user. The consumer would then use the authorization token with the original request secret to receive an authorized access token. > 4. And, should the new parameter be added to 6.3.1 (oauth_token + > oauth_something) or replace the value of the oauth_token parameter? It should replace the value of the oauth_token. There's no reason to use a value that an attacker can already know. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/26/09 12:03 AM, Josh Roesslein wrote: > How would a desktop client receive a callback? For example, on an iPhone, you can register a custom URI scheme, i.e., instead of the callback being in the form "http://..."; you would use a callback like "myuri://..." which the browser would use the registered URI handler - in this case, the desktop app - to process the request. > I don't really see it practical for desktop clients to use callbacks. This is why you shouldn't be suggesting solutions that merely create more noise that makes it harder for others to work on a proper solution. Sorry, the round-and-around about "solutions" that aren't is getting old. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
In some cases, the consumer "secret" is not very secret. The response "too bad" is not acceptable. There is no reason why an authorization spec. can't be designed to work in such a case. -- Dossy Shiobara do...@panoptic.com -Original Message- From: Josh Fraser Date: Sat, 25 Apr 2009 17:05:17 To: OAuth Subject: [oauth] Re: OAuth Security Advisory How would attackers be able to inject a callback w/o having access to the consumer secret? On Apr 25, 3:46 pm, Josh Roesslein wrote: > Zack, very good points. We have been probably over thinking this a bit and > have gotten off topic. > > Our focus should be: > > + Secure the callback in the authorization URL from tampering > + Make sure the user that authorized the request token is the same user that > requested it > > The first issue can be solved by signing the callback URL if it is included > in the authorization URL. Since devices / apps wont' use a callback, the > consumer > should set a flag during provider registration saying it will not use > callbacks. This will prevent attackers from injecting a callback. > This still allows for clean authorization URLs that are easy to type > manually. > > We can solve the second issue by requiring a "confirmation token" be > included with the callback. > If there is no callback, the user must manually enter is confirmation back > into the consumer. > The token should be type able, but long enough to make brute attacks > unlikely. > > These changes are easy to implement and don't really affect the current > oauth flow. > > On Sat, Apr 25, 2009 at 4:31 PM, Zachary Voase > wrote: > > > > > I completely agree. The whole point of this thread (I thought) was to > > develop a solution to a very specific security hole; this has already > > been done with three things: once-only exchanging, signed/pre- > > specified callbacks, and the concept of a callback nonce (a.k.a. > > authorization token, and a host of other names) (have a look at a > > previous post by Mike Malone for the details). These things require > > absolutely *no* change in user experience, they keep all of the burden > > of verification/authentication on the service provider (where it > > should be), and they need only minimal changes to the specification. > > We can't trust consumers to verify things, because that means the > > service provider is trusting a third-party with the security of its > > users' data. > > > I suppose what I'm saying is that if you think you've got a totally > > better authorization protocol/strategy worked out, great, but let's > > try and keep the focus on patching this security hole rather than > > completely rewriting the spec. > > > You might also be interested in reading the OAuth design goals for an > > explanation of why things are the way they are: > >http://oauth.net/about/design-goals > > > Regards, > > Zack > > > On Apr 25, 10:56 pm, "J. Adam Moore" wrote: > > > Yeah, I have that at my bank and it sucks all kinds of hell. Thank god > > > I can just Google my mother's maiden name to reset my password when > > > that fails. If a system is designed to work only by relying upon > > > people to not be stupid it will fail. You can't outwit a fool; only > > > fools try. I really need to finish my post on this. It has pictures > > > and everything. Should clear up some confusion people might have. > > > > I am not saying that your method is forever flawed, but why change > > > OAuth when it works just fine? Remember, the problem we are facing is > > > still theoretical and the solution I proposed doesn't break anyones > > > current or past work or understanding. > > > > On Apr 25, 1:33 pm, Josh Roesslein wrote: > > > > > The only place that a phishing attack would occur in the signed > > > > authorization proposal is the authorization URL. > > > > An attacker could lure an user to click on a link that directs the user > > to a > > > > clone of the provider and steal the users credentials > > > > when logging in. The best way to prevent this is users being careful to > > > > check the address bar and making sure the site they are at > > > > is indeed the provider's site. Another layer that can help prevent this > > is > > > > by using images that are displayed on the provider's site during login. > > Some > > > > banks use this during login. You first give your username and hit > > enter. > > > > Next the bank shows an
[oauth] Re: OAuth Security Advisory
This also has the added benefit of letting consumers use a provider as an identity surrogate, relying on the user's ability to authenticate w/ the provider, i.e., the recent "Sign in with Twitter" style functionality. -- Dossy Shiobara do...@panoptic.com -Original Message- From: "J. Adam Moore" Date: Sat, 25 Apr 2009 12:58:20 To: OAuth Subject: [oauth] Re: OAuth Security Advisory EDIT LAST POST: The second "consumer" I meant to say provider. On Apr 25, 12:55 pm, "J. Adam Moore" wrote: > What I should have added was that using my solution, the consumer is > completely capable of being stupid and giving the consumer a redirect > that doesn't require a login on the consumer side, but they can also > take a gun and blow their brains out. You can't stop people from being > stupid and it's not the Providers job to even care if the redirect > they were given is secure. > > I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything works > exactly as before EXCEPT the request token HAPPENS AFTER > AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes > everything. Triggering the authentication flow AS IT IS NOW from > behind a login ON THE PROVIDER SIDE. An attacker cannot generate a > reusable token or spoof/calculate an access token. Totally secure > would be the scenario I explained where both sites redirect behind a > login. It's simple. It's easy. Lets do it. > > On Apr 25, 12:41 pm, "J. Adam Moore" wrote: > > > Logically I find that the only way to guarantee that two different > > users at two different sites are really the same person is to make > > them self authenticate BEFORE establishing a secure communication. By > > having both the Provider and Consumer redirect to a spot behind a > > login on both sites it fulfills this requirement without breaking the > > current model or people's brains. Making something simpler for the > > sake of simplicity is simply not a compelling argument against > > requiring habeas corpus at each end. I think too many people are > > trying to adjust the model instead of the implementation. The model is > > fine once you can prove (on each end) that it is the same user. Not > > caring what your login is on the consumer? What does that even mean? > > Either the redirect url is publicly accessible or it requires a login. > > I don't need to know WHO you are or care if you are logged in or not, > > but nothing is going to happen until you prove that you are who you > > are trying to associate with. This also leaves sites able to craft > > their redirect urls to contain either unique paths or unique tokens or > > both without breaking the protocol or damaging the current information > > exchange model. I still favor a solution that doesn't add or take away > > anything from the current model. Basically a protocol that reorders > > passing information to occur after user authentication and tightens > > rules on where redirects point. > > > On Apr 25, 12:12 pm, Josh Roesslein wrote: > > > > We don't really need the user to be logged into the consumer to generate > > > our > > > token. The service provider should not care what our login is on the > > > consumer. > > > All it cares about is authorizing a consumer access to our data. We log > > > into > > > the provider and authorize the creation of an access token for the > > > consumer. > > > We then visit this consumer and hand over our token (either manually for > > > desktop apps or by being redirect by a callback w/ token attached). > > > The consumer can now access our data. It is up to the consumer now on how > > > to > > > store this token. (Here is a link to the > > > flow:http://pastie.org/pastes/457478) > > > > I don't think preventing middle attacks or phishing is really what oauth > > > should be doing. SSL does this well and it should be used for the transfer > > > of the token > > > from the provider to the consumer. This way an attacker can't intercept > > > the > > > token and use it to log in to the consumer under their account and access > > > our data on our provider account. > > > > The user can't be easily phished since both URL's (authorization URL and > > > callback URL) are verifiable by SSL. Also the callback is either stored on > > > the service provider or signed in the authorization request by the > > > consumer. > > > > On Sat, Apr 25, 2009 at 1:43 PM, J. Adam Moore > > > wrote: > &g
[oauth] Re: OAuth Security Advisory
On 4/25/09 1:33 PM, J. Adam Moore wrote: > I'm writing a blog post to explain why I think I have a solution, but > I believe it is as simple as moving the provider login to before the > consumer token generation which is triggered by a provider-side > redirect. Yes. This is exactly what I've been saying. Please, help me help others understand this, too. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/25/09 12:31 AM, pkeane wrote: > If I am following correctly, this should work. But there are a few > drawbacks I see. It is fairly dramatically different from the way > OAuth works now for all parties: user, consumer, provider. Right. OAuth, as it is specified in 1.0, has flaws that will require changes that affect all parties. > It also seems quite complex (maybe I am being dense :) to me, a > hallmark of a good security scheme is simplicity and clarity to the > extent possible. I dunno, it seems remarkably simple to me. Matter of fact, I don't see any ways to make it any simpler without losing important security. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: San Francisco meetup this Tuesday 5pm
On 4/24/09 5:42 PM, Leah Culver wrote: > OAuth Meetup > Tuesday, Apr 28th at 5pm > Six Apart > 548 4th Street Darn, I'd love to participate but at 8pm US/Eastern time, I'll be at a Grateful Dead concert. Argh! -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
s him immediately back to Gmail's authorization callback. 6) Gmail then performs a server-to-server request upgrading the request token to an access token. (At this point, the request token is no longer valid or usable.) 7) Gmail proceeds to use Flickr's API using Bob's authorized access token. Any questions? -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 1:18 PM, Zachary Voase wrote: > The point I'm trying to make is that this is an intractable problem; I > don't know how to explain it in clearer terms than this: the issue is > one of being able to read the user's mind and find out if they are who > they say they are. The two-point solution I'm trying to push ensures > that requests are as authentic as possible.*Any* solution will be > heuristic because of the architecture on which OAuth works (a > combination of HTTP, TCP/IP, and Homo Sapiens). It's not an intractable problem. There's no mind-reading required, just a design that isn't flawed by design. I have yet to see anyone explain why my proposal of authenticating with the SP _first_ before starting the authorization flow with OAuth does NOT eliminate this risk _completely_. Someone please shoot a hole in the idea if it's at all possible. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 12:30 PM, Zachary Voase wrote: > But we've pretty much solved*that* issue with signed/pre-specified > callbacks and the once-only rule for exchanging request tokens. Not solved, but minimized. That's what worries me. Are we collectively happy with "secure enough" until someone implements a proof-of-concept exploit that's released in the wild? Why does it have to come to that before we really do the right thing? -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 11:47 AM, Zachary Voase wrote: > Can someone please cut the Gordian knot and make a decision? Would it help if I invoked Godwin's law, too? ;-) -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 12:18 PM, Zachary Voase wrote: > But I think people are missing the idea that the consumer can just use > sessions and cookies to ensure that the browser which asked for the > request token is the same as the one which is authenticating it. > There's no need whatsoever for callback tokens, etc. I think you're missing the fact that the attacker is the one using the consumer. The victim is just sent to SP to authorize the attacker's token with _the victim's_ identity, which then makes the attacker's session at the consumer access the victim's resources at the SP. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 11:50 AM, Zachary Voase wrote: > On Apr 24, 5:20 pm, Luca Mearelli wrote: >> > I'd say that if the application has the concept of an identity it >> > should be a sensible practice to generate it beforehand and educate >> > its users to recognize it (it would work as an anti-phishing measure). > > Isn't it better to spend the time and effort educating users on when > to give access to third party applications and when to deny it? Any "solution" that depends on "educating users" is already doomed to fail. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 11:12 AM, pkeane wrote: > This is correct, but it's important to point out that you have thus > created an authentication mechanism (and authentication is hard). Federated Identity Barbie says, "Authentication is HARD!" Indeed, I don't think OAuth should specify HOW to authenticate a user, but it should be cognizant of the need for authenticated users and passing an authentication token around. _How_ an SP authenticates its user is left as an exercise to the reader. :-) -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 4:35 AM, Manish Pandit wrote: > A little off-topic, but I always wondered the lack of > "revoke_access_token" endpoint. If the victim were to find out that > his account has been compromised, what options does he have? Some > providers (I know I would) may provide the revoke_access_token > endpoint but shouldnt the spec kind of make it standard like the other > 3? This should really remain OUTSIDE the scope of the OAuth spec. It should be strongly recommended that a SP provide a UI for managing authorized consumers, but that is not required to effect authorization between a consumer and SP. And no, I wouldn't trust a consumer to initiate the token revocation flow. Hahaha. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 3:54 AM, Leah Culver wrote: > The attacker would need to call the access token endpoint with a request > token that is both authorized and has not been sent to the endpoint > before. Since the attacker has no way of knowing if their token is > authorized or not at any point in time*, it's up to luck and is a pretty > inefficient scam. > > * without a malicious callback Let us observe that email spam is proof-positive that "inefficient" won't prevent "attacks" - as long as payout is non-zero and cost approaches zero, someone will do it if they are seeking the outcome. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Issue: Referer
On 4/24/09 3:25 AM, Manger, James H wrote: > A (temporary) fix might be for Service Providers to check the HTTP > Referer request header when Users arrives at the authorization URI. This is a non-starter as users behind anonymizing web proxies are screwed. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 3:23 AM, Mike Malone wrote: > The callback nonce would make it impossible for the attacker to forge > the response without changing the callback (access token exchange would > fail). And any of the three mechanisms listed above would secure the > callback. That should be sufficient to eliminate the threat. ... "except in the case where the shared secret is freely available, such as desktop applications." If there's going to be a revision to the spec., we should collectively take the opportunity to FIX it completely, including desktop and mobile applications or in any situation where the shared secrets are potentially revealed to an attacker. Instead of a callback nonce, we need to start the whole process with an identity nonce (the "authentication token" I keep referring to) that the Consumer must use in order to initiate the entire authorization flow. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 1:15 AM, pkeane wrote: > But I still have a sense (as Dossy above suggested) that OAuth in its > 3-legged form must address the need for an authentication mechanism. > As Eran said in his post, the three pieces: (A) get request token, (B) > authorize request token, (C) get access token need to "all" be > connected. [...] > > The weakness is in the A-B connection. There are numerous ways to > mitigate the risk& I think user experience and security strength are > inversely proportional. [...] I agree. What about this kind of process: 1) Consumer sends User to Provider to authenticate. 2) Provider authenticates User and sends them back to Consumer with an authentication token. 3) Consumer issues a request token from Provider. 4) Consumer sends User to Provider to authorize the request token. 5) User (already authenticated with Provider) authorizes the token. 6) Provider sends User back to Consumer. 7) Consumer upgrades the request token to an access token from Provider. Now, the worst-case UX here is two interactions at Provider, one to authenticate and one to authorize. Note: This is NO different than the current UX, where the Provider has to authenticate the User before allowing them to authorize the token in the current spec! I am simply requiring that the authentication step happen with a different timing than the current spec does. The best-case UX is that the User has previously authenticated with Provider and has previously authorized the Consumer. In this case, the User is simply bounced back and forth between Consumer and Provider twice, but requires no actual interaction. IMHO, this is the "ultimate" good UX possible. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/24/09 12:27 AM, Leah Culver wrote: > *1. One time only token exchange* > > I actually agree with the suggestion to keep the access token endpoint > one-time only. This means that you only get one chance to exchange a > request token for an access token. Glad I'm not the only one. Thanks. > *2. No callback request parameter* > What about using a callback to guarantee a successful exchange? > > I'm a fan of eliminating the callback as a request parameter altogether. > Allow the consumer to register a callback when they register their > application. I've been trying to think of a scenario where a consumer > would want a dynamic callback, but I can't think of anything that can't > be dealt with (via a redirect) after the OAuth dance is over. What's the problem with requiring the callback URL in the server-to-server request for a request token, at which point the SP associates the URL with the request token, and no longer allowing it on the authorize URL? This would allow for dynamic callback URLs but eliminate an attacker's ability to manipulate the callback URL as long as they aren't privy to the consumer secret and request secret. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 9:26 PM, Brian Eaton wrote: > That's not a good user experience, nor is it necessary to fix the > security problems in the protocol. Let me say it another way: yanking support for OAuth in response to security issues is even worse user experience. Define the spec. such that it is sufficiently secure, then in future revisions work hard to pare it down to what is necessary and sufficient in order to improve the user experience. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 9:26 PM, Brian Eaton wrote: > A flow like this? > 1) User visits SP, gets "identity token" > 2) User enters "identity token" into desktop app. > 3) Desktop app sends user back to SP again. > 4) User approves access at SP. > 5) User goes back to desktop to approve access. Something like this, right, except (5) is more like "User uses desktop app." > That's not a good user experience, nor is it necessary to fix the > security problems in the protocol. Perhaps not necessary, but definitely sufficient. What folks feel is necessary in order to preserve "good user experience," if it is not sufficient to remove the risk, is worthless. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 9:06 PM, Brian Eaton wrote: > The current version of the protocol is susceptible to a very similar > attack for web applications, which is why people are so upset and > working on a fix. I won't go into those details until a reasonable fix is available. :-) > For desktop apps, it's hard to do better, and even once we have a fix > for web apps it's likely that people will keep using OAuth 1.0 for > some desktop apps. There are a few options. Why is it hard to do better? Perhaps it's hard to do better without affecting the user experience, but that's the cost of open interoperability and security. > 1) Keep using OAuth 1.0. > SPs can tell users that they are authorizing an application on > their desktop. There is some risk of social engineering as you > describe, but hopefully the language on service provider pages > mentioning desktop applications will help. The problem here is that attackers can leverage other vulnerabilities (in browsers, in provider implementations, etc.) to make the victim's active participation entirely unnecessary. Social engineering is clearly the easiest attack vector, but not the only one here. > 2) Callback token displayed on page. > SPs can display a callback token, which the user will manually > enter into their desktop application. This is not a good user > experience, but provides better security than option 1. Not sure about the language of "callback token" here, which to me implies something that happens during or after the process is complete. What we need is an "identity token" - something that an authenticated user requests from the Provider and feeds it into the Consumer which it can use to begin the request+authorization flow. This is why I respond to people who love to point out that "OAuth isn't an authentication scheme" with "I know and I hope we can correct that sad oversight." > 3) Callback token sent to desktop app. > There are a bunch of ways to get a callback token to a desktop app > automatically, most of them mentioned earlier in this thread. I'll have to think more deeply about the security of this suggestion before I comment. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 9:00 PM, pkeane wrote: > actually, I would say you need to make sure the person initiating the > request is the same person initiating the authorization. It needn't > be tied into actual user accounts. As far as I understand, consumers > might not even have a notion of "user" beyond session state. That's > why I had suggested PIN, but Right. The obvious solution is to require the user to _authenticate_ with Provider in ORDER to first get a request token, which can then be _authorized_. This way, an attacker can't generate a request token for a user they can't first authenticate as, so that there's no request token to pawn off on a hapless victim to authorize. Somewhere, fairly loudly, I'm sure the AOL Screen Name Service people and MSN Passport folks are laughing at all of us. And, rightfully so. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 8:46 PM, Brian Eaton wrote: > OK, you lost me. Can you summarize the attack again, this time > leaving out the bit where malicious software is running on the > computer and scanning memory for access tokens? Alice (attacker) and Bob (victim). Both Alice and Bob run Consumer (application). This is legitimate, trust-worthy software. It uses OAuth to access Provider (service). Alice runs Consumer with memory inspection software to recover the consumer key and secret. Alice then elicits Consumer to request a Request Token and Request Secret from Provider, and uses the memory inspection software to recover these. Alice then somehow convinces Bob to click on a link to Provider that authorizes the Request Token that Alice is holding. Bob unwittingly authorizes the token. Alice is now holding all the tokens and secrets necessary to upgrade the Request Token to an Access Token that is authorized with Bob's account. Game over. Please, I can't make this ANY clearer than this. If you don't understand this explanation, please ask clarifying questions that hopefully someone else can take a stab at answering because I'm all out of ideas here. I have pretty much supplied above all the necessary details to implement a working exploit against current OAuth 1.0 implementations, leaving nothing out in hopes that everyone can understand the threat. I'm so sorry ... -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 8:30 PM, Brian Eaton wrote: > Malicious software on the user's computer does not need to steal > access tokens. It steals passwords, bank account numbers, and > confidential documents. Sure. But, this attack can happen when the victim is NOT running malicious software! That's why this is a serious threat. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 7:10 PM, Zachary Voase wrote: > An application such as iTunes (which keeps DRM > decryption keys in memory) is also subject to similar issues, but I > don't think anyone's yet made a viable attack against that. In my mind, there's a significant difference between breaking DRM vs. gaining unauthorized control over a user's account. And, again, merely not having an implemented exploit doesn't make the threat any less trivial to implement or dangerous once it is. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 6:00 PM, Zachary Voase wrote: > * If the consumer is a desktop app, then a few things might > happen. MU could start brute forcing the access token, which would > lead to one of a couple things: If the consumer is a desktop app., then the attacker has access to the token secret through application memory inspection. Consider: 1) Alice (the attacker) and Bob (the victim) both use desktop application Consumer. Alice uses Consumer to request a request token and secret from Provider. 2) Alice tricks Bob into authorizing the request token as Bob. 3) Alice takes the authorized request token and secret and upgrades it to an access token. 4) Alice now holds an authorized access token and secret that has access to Bob's account. This is a very real threat vector. Lets fix it. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
On 4/23/09 2:46 PM, Mike Malone wrote: > There's still a timing attack for the manual case because the attacker > could sit on the callback page for the consumer and repeatedly submit > the request token key, possibly beating the victim there after the token > has been authorized. The solution is to have the user enter two numbers > in the manual case. The request token key, and the callback nonce (which > could be a short PIN, as Eran suggested). How about just making the request token a one-shot token which becomes invalid after an access token upgrade request, whether it succeeds or not? This doesn't eliminate the race but it makes it a LOT harder to brute force, as it does NOT allow an attacker to hammer the callback URL, as the first request to the callback URL, if it comes in before the request token is authorized, will invalidate it. Sure, this results in a poor UX for the legitimate user who's being attacked, but this is sure better than leaving the window of opportunity so large. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: OAuth Security Advisory
+1 on Matt's solution below, with the following caveat and concern:
What about apps that send the user off to authorize the request token
and do not utilize the callback (i.e., non-web applications).
Primarily, these would be desktop applications and such that will send
the user to the authorization URL in a launched browser, but have no
means of calling back to the non-web app. and simply rely on the user
closing the browser and returning to the app. and indicating that
they've authorized it.
In this case, the OAuth Consumer could signal to the Provider through
server-to-server communication (e.g., through the request method) that
it DOES NOT support the callback, and instead the Provider should end
the UI flow by displaying a token ("authorization key") that the user
manually brings back to the Consumer which it then uses when requesting
the access token for that request token.
Thoughts?
On 4/23/09 1:31 PM, Matt Sanford wrote:
> Hi Mike,
>
> I have a proof of concept I think might be similar to this. It works
> like so:
>
> 1. When the consumer gets the request_token the provide the callback URL.
> » Note this is server-to-server communication, unavailable to the user.
>
> 2. The user is redirected to the service provider to authorize the
> application.
>
> 3. Once authorized the user is redirected the the callback URL with an
> additional callback_token parameter.
>
> 4. When requesting the access_token the consumer provides the
> callback_token.
> » If the request_token has a callback but the access_token request does
> not have the callback_token access is denied and the request token is
> invalidated.
> » If the request_token had no callback but the access_token request does
> access is denied and the request token is invalidated.
> » If the callback_token does not match the one on record access is
> denied and the request token is invalidated.
>
> By sending the callback in the server-to-server communication it is not
> available to the user/attacker. This is also a signed request so
> man-in-the-middle changes to the oauth_callback will be caught by the
> signature. The final step of checking the callback_token prevents other
> man-in-the-middle style attacks after the user has been returned to the
> consumer app. Does this sound like what you're suggesting?
>
> Thanks;
> – Matt Sanford / @mzsanford
> Twitter API Developer
--
Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~--~~~~--~~--~--~---
[oauth] Re: http://apiwiki.twitter.com/Sign-in-with-Twitter
On 4/18/09 5:43 PM, John Kristian wrote: > Could you describe an attack scenario, please? I don't know what > 'token shooting' means. Attempts to invoke the callback URL, guessing tokens (either iterating through brute force or some other pruning technique). > And I don't understand the vulnerability to a replay attack. If an attacker can invoke code at will that's in the _middle_ of an authentication process flow, the end results can be deleterious. Sure, "robust code" should defend against all reasonable attacks, but _why_ put extra burden on the OAuth Consumer when simply signing the callback URL eliminates it all? -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: http://apiwiki.twitter.com/Sign-in-with-Twitter
On 4/17/09 7:00 PM, John Kristian wrote: > OAuth concentrates on securing communication between the consumer and > service provider. The callback is just a timing signal, telling the > consumer it can continue its interaction with the service provider. > Nothing sensitive is transmitted via the callback. > > In other words, attempting to transmit something sensitive via an > OAuth callback is a mistake. OAuth wasn't designed for this. Oh, I don't care about transmitting sensitive data via the OAuth callback. I just want to eliminate replay attacks - you're absolutely right, the callback is a form of IPC to the consumer ... which presumably will go on to perform other tasks once it receives the signal. Depending on what those tasks are, it's very desirable to be able to tell if the callback was legitimate or either a replay attack or a brute-force token shooting attack. Even client-side browser cookies may not win here if a simple session fixation attack is coupled with the token shooting attack. Exactly what's the harm in signing the callback URL? -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: http://apiwiki.twitter.com/Sign-in-with-Twitter
On 4/17/09 4:20 PM, Dirk Balfanz wrote: > Why? OAuth doesn't need it. It's not an authentication protocol. That's such a sad oversight of the initial OAuth specification. I hope we can fix this in future versions of the spec. > Once you start going down this route, you'll realize that you also > need replay-protection, etc., and before you know it you have > re-invented OpenID. I thought the signing mechanism defined by OAuth 1.0 provides replay-protection, and everything that's included in "etc." that you hint at. Currently, the OAuth callback URL is susceptible to replay attack and token shooting. Signing it would eliminate this in a very low-effort way. -- Dossy Shiobara | do...@panoptic.com | 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: http://apiwiki.twitter.com/Sign-in-with-Twitter
On Apr 17, 10:32 am, Breno wrote: > Sorry, Eran, but it is not an authentication protocol. An > authentication protocol must be signed by the authenticator, not by > the authentication requester. OMG YES! Can OAuth 1.1 _please_ fix this and make signing of the callback URL by the OAuth producer back to the consumer a REQUIRED part of the specification? Yes, I recognize that this may result in problems w/r/t URL length limits as all the values are passed as query parameters in a GET request, but it would be SO worth it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
