On Apr 24, 12:28 am, Luca Mearelli luca.meare...@gmail.com wrote:
On Fri, Apr 24, 2009 at 7:15 AM, pkeane pjke...@gmail.com wrote:
The weakness is in the A-B connection.
...
Whatever happens, I think the consumer is
going to need to signal to the user that it is about to make contact
It seems like a lot of the vulnerability concerns (at least from B-C)
can be addressed by simply adding the callback to the signature. Is
there a reason this wasn't included in the spec to begin with? I want
to make sure I'm not missing something.
On Apr 23, 11:57 pm, Eran Hammer-Lahav e...@hueniverse.com wrote:
Do you mean why the callback itself isn't signed? Or the parameter?
EHL
I think he meant signing the request that includes callback as a
parameter for authorizing the request token (6.2.1 from the Spec).
I agree that it will
It's a good idea. The problem is that it's trivial to fake a referrer
header. All you need to do is tinyurl a link (to avoid suspicion)
that redirects you to the authorization url via a proxy that adds the
expected referrer header.
On Apr 24, 1:25 am, Manger, James H
On Fri, Apr 24, 2009 at 12:23 AM, Mike Malone mjmal...@gmail.com wrote:
On Thu, Apr 23, 2009 at 11:43 PM, Manish Pandit
pandit.man...@gmail.comwrote:
On Apr 23, 11:04 pm, Josh Fraser joshf...@gmail.com wrote:
Leah,
*
2. No callback request parameter
*
What if we make
On Fri, Apr 24, 2009 at 10:04 AM, Josh Fraser joshf...@gmail.com wrote:
Don't requests for access tokens need to be signed with the consumer
secret?
correct (at least for web consumers)
This means that an attacker needs the victim to return to the
consumer site to complete the handshake
On Apr 24, 1:04 am, Josh Fraser joshf...@gmail.com wrote:
Manish,
I may be leading you astray regarding the importance of the callback.
Forgive me as I struggle to wrap my head around all of this.
Who isnt struggling to wrap their heads around this..its 1:30a and I
cant sleep :)
Don't
On Fri, Apr 24, 2009 at 10:35 AM, Manish Pandit pandit.man...@gmail.com 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)
On Apr 24, 5:31 am, Zachary Voase disturb...@googlemail.com wrote:
I've read all of the messages on here up until now, and so far (to
summarize) there have been three main points which have been repeated
quite a few times:
1) If you're going to specify a callback, you've got to sign it
Paul Lindner:
Proposal number two I call Tight User Binding.
One issue with OAuth is that you are defacto granting access to your account
to an entire consumer key, which is generally an entire web site or client.
If a provider caches this authorization and automatically redirects to a
Great discussion!
If I'm correct we'd be OK if, during the authorization step, SP could get a
confirmation that the user whom has just authenticated is the same than
the one that triggered the 1st step at the Consumer (request token retrieval).
How about something like:
- Since in the std
Actually we'd want to do that step after authentication and before
authorization.
Hubert
On Fri, Apr 24, 2009 at 3:41 PM, Hubert Le Van Gong hubert...@gmail.com wrote:
Great discussion!
If I'm correct we'd be OK if, during the authorization step, SP could get a
confirmation that the user
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.
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
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
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
The HTTP Referrer check won't work if the Consumer's domain is a social
networking site, and the attacker posted the authorization link to the
victim's wall.
Allen
Manger, James H wrote:
A (temporary) fix might be for Service Providers to check the HTTP
Referer request header when Users
Because we didn't consider the callback a core part of the flow at the time. It
was just a usability optimization (most providers at the time used a
pre-registered callback). Also, the authorization call itself is not signed
because in some cases, the application cannot redirect the user or
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,
On Apr 24, 8:50 am, Zachary Voase disturb...@googlemail.com wrote:
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?
It is a much needed strategy, but again, not a solution.
-cheers,
Manish
OK, I definitely see what you mean with the callback nonce now and I
completely agree that it plugs that last hole (where the attacker
beats the user to the callback URL). Most of the messages preceding
this one talked about callback nonces as these things that get
generated with the request
Mike,
Thanks for clearing up our terminology around the callback nounce.
On Apr 24, 11:24 am, Mike Malone mjmal...@gmail.com wrote:
Personally, I don't think a callback nonce is going to do much at all
to stop people from carrying out this attack. I've already said this
twice in this
On Apr 24, 12:40 pm, Zachary Voase disturb...@googlemail.com wrote:
OK, I definitely see what you mean with the callback nonce now and I
completely agree that it plugs that last hole (where the attacker
beats the user to the callback URL). Most of the messages preceding
this one talked
I've since had the whole concept of callback nonces explained to me by
Mike Malone in an earlier post here and so I retract what I said
before about callback nonces (I had a different idea of what they
were).
On Apr 24, 8:24 pm, pkeane pjke...@gmail.com wrote:
On Apr 24, 11:37 am, Zachary Voase
On Apr 24, 11:37 am, Zachary Voase disturb...@googlemail.com wrote:
But the protocol's already very secure on most fronts, and I meant in
terms of if the changes suggested here time and time again had been
implemented (signed/pre-specified callbacks and the once-only rule for
exchanging
On Apr 24, 1:29 pm, Dossy Shiobara do...@panoptic.com wrote:
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
I've got a potential simple solution.
1. User goes to photoeditor.com.
1a. The user creates an account
or
1b. The user is prompted to enter a word/phrase familiar to them, if
the consumer is not a user account-based site.
2. When the token is requested, this username or
On 4/24/09 2:42 PM, pkeane wrote:
I'm pretty sure it does. Let me see if I can sketch out the scenario:
1. user goes to photoeditor.com to edit some photos. photoeditor.com
gives me a menu of partners that I can use photos from: Flickr,
Picasa, etc.
2. I select Flickr and I am immediately
How about this idea...
Instead of the Request token -- Redirect to Service provider w/ token
process how about just redirecting
straight to the service provider with just the consumer ID in the
URL.
1. User visits Consumer site and can optionally register an account.
2. Consumer registers
Actually after some more thought I have come up with this new
revision:
1. User visits authorization URL that directs them to the service
provider's site.
This link can be provided by the consumer.
Example: http://www.pictureland.com/oauth/authenticate?consumer=printit.com
2. User
Correction:
It is now up to the service provider to bind this token to an account
or session.
should be
It is now up to the consumer to bind this token to an account
or session.
On Apr 24, 3:23 pm, joshthecoder jroessl...@gmail.com wrote:
Actually after some more thought I have come up with
Hi all,
My eyes hurt from trying to read long email threads. There's quite a
few good ideas for helping protect against the current security issue
and it will be helpful to get together to discuss. Here's the details:
OAuth Meetup
Tuesday, Apr 28th at 5pm
Six Apart
548 4th Street
I'll try to
Hey Josh,
Sorry I lost your message in the long thread.
On Thu, Apr 23, 2009 at 11:04 PM, Josh Fraser joshf...@gmail.com wrote:
Leah,
*
2. No callback request parameter
*
What if we make the callback optional? Consumers can either:
a) leave it out altogether in which case the
Yes it eliminates the request token and basically skips to step D. I don't
really see the need for request tokens.
We can just direct the user to the service provider's URL for the consumer,
authenticate, and return the access token in the callback.
in the callback that is given when the consumer
On Apr 21, 7:32 pm, Zhihong zhih...@gmail.com wrote:
I'd like to find out how many people are interested in using JMeter to
test OAuth-based services. We developed a plugin and like to
contribute it back to JMeter. If enough people are interested, we will
push to make it part of JMeter
On Apr 24, 2:42 pm, Leah Culver leah.cul...@gmail.com wrote:
Hi all,
My eyes hurt from trying to read long email threads. There's quite a
few good ideas for helping protect against the current security issue
and it will be helpful to get together to discuss. Here's the details:
OAuth
The OAuth spec is silent on how to handle section 5.2 when an HTTP PUT
|POST might be used to send in OAuth parameters AND resource content.
For example, an OpenSocial endpoint uses OAuth for authentication and
may post an XML encoded version of a Person. In this case, does a
compatible OAuth
Hey,
On Fri, Apr 24, 2009 at 5:52 PM, Manish Pandit pandit.man...@gmail.comwrote:
On Apr 24, 2:42 pm, Leah Culver leah.cul...@gmail.com wrote:
Hi all,
My eyes hurt from trying to read long email threads. There's quite a
few good ideas for helping protect against the current security
On Apr 24, 6:02 pm, Scott Seely sse...@myspace-inc.com wrote:
The OAuth spec is silent on how to handle section 5.2 when an HTTP PUT
|POST might be used to send in OAuth parameters AND resource content.
For example, an OpenSocial endpoint uses OAuth for authentication and
may post an XML
I'd like to propose the following flow (which is basically an
amalgamation of a few ideas throughout this thread):
1) User visits Consumer's website, Consumer gets request token
from Service Provider.
2) Consumer sends user to the Service Provider's user auth URL,
with 'oauth_token' and
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
I can make it!
On Apr 24, 2009, at 6:12 PM, Leah Culver wrote:
Hey,
On Fri, Apr 24, 2009 at 5:52 PM, Manish Pandit pandit.man...@gmail.com
wrote:
On Apr 24, 2:42 pm, Leah Culver leah.cul...@gmail.com wrote:
Hi all,
My eyes hurt from trying to read long email threads. There's
Manish,
Judging from the responses, it's probably better to leave the plugin
as is. I am in the process of contributing source somewhere.
Meanwhile, send me Email (zhihong at gmail) if you want try it out.
For some reason, I can't get your Email from profile.
Zhihong
Let the folks on the
I guess you could say the flow I proposed is a one token exchange. There is
only the access token that is returned back to the consumer
from the authorization callback.
As for the whole callback parameter, I don't like it at all. I see it as bad
practice of dynamically setting this URL.
It should
44 matches
Mail list logo
