I'd like to see an extension for body signing. It's pretty trivial to
do, but having it standardized somewhere so that libraries can be
written to handle it would be nice.
Alternatively, you could just use HTTPS.
Mike
On Wed, Nov 4, 2009 at 1:56 PM, Brian Eaton wrote:
>
> On Wed, Nov 4, 2009 a
If the client provides the oauth_callback parameter when it asks for a
request token then it's using the new flow. The oauth_callback
parameter is required in 1.0a exactly for this reason. If the client
doesn't want to provide a callback, or if the callback is provided
some other way, the oauth_ca
> I think the only affected implementation is the plain text signature,
> which I really never thought should have been part of the standard in
> the first place. Does anyone actually use that?
Please explain. How does this effect plaintext any differently than
the other signature methods?
Mike
>>> Seth, I actually think that enforcing nonces should make this attack
>>> impossible for guessing OAuth signatures (assuming you enforce nonces
>>> for malformed requests). If you can only get a good/bad response once
>>> then you're out of luck.
>>
>> I was thinking that the attacker would be
I'm no security expert, but I'm gunna go ahead and say that (IMO) this
attack is at best a theoretical attack for the vast majority of OAuth
installs.
> Blaine or Kellan threw out a question about this vulnerability in an
> OAuth context that I haven't had the time (nor do I have the
> qualificat
Eran's right, there are ways around this, but I'm wondering what sort of
mobile device you're working with that doesn't have the capacity to sign
each request. It's really not that much overhead unless you're making
hundreds or thousands of requests per second (which is unlikely on a mobile
device)
It'd be a huge win if Google Reader would support this. It would probably be
enough to convince most other readers that they need to support it too.
Google people, I know you're reading this. Do it! :)
Mike
On Thu, Jun 4, 2009 at 11:15 PM, John Panzer wrote:
> On Thu, Jun 4, 2009 at 10:31 PM, C
FWIW, if we're still tallying votes, I vote for option 1.
On Fri, May 1, 2009 at 2:34 PM, Eran Hammer-Lahav wrote:
>
> That was not what I did. I was just explaining how this process works and I
> clearly stated the need (and the full historical record) of getting to
> decisions by consensus. Thi
On Thu, Apr 30, 2009 at 2:14 PM, Owen Evans wrote:
> Ok but can I just confirm that the only way to do late binding is to have
> some parameter in the callback that identifies which Request Token was
> authorised/denied? Just want to make my understanding clear as there's
> nothing in the spec th
esn't receive
> the call-back and relies on the user to tell the application that the step
> is complete there's no way of the application knowing which request token
> was authorised and must have a link between the user and request token prior
> to sending the user to the
On Thu, Apr 30, 2009 at 11:59 AM, Josh Roesslein wrote:
> Here is some pseudo python code of what I have in mind for a more higher
> level library: http://pastie.org/464241
>
> This is not a final design, there are other details I have left out, but it
> demonstrates the flow for the consumer of a
> I hadn't thought of late binding as the path of least resistance, so
> perhaps I'm making a bigger deal of this than I need to, although it
> occurs to me that some developers will be tempted to store the request
> token in the current session, which is really easy in most
> environments, and doe
On Thu, Apr 30, 2009 at 10:57 AM, Blaine Cook wrote:
>
> On Thu, Apr 30, 2009 at 6:54 PM, Mike Malone wrote:
> >
> > This would break the web flow for 1.0 (non Rev. A) consumers.
>
> I think that's the desired behaviour, though? So long as service
> providers co
> From Eran's summary of the proposal there are three ways to close the loop:
>
> (1) Verifier + Callback
> (2) Verifier + Manual entry
> (3) No verifier + manual 'continue'
>
> The options for the SP would be:
>
> oauth_callback in 1st step:
>
> - Present with value - do (1)
> - Present with empty
On Thu, Apr 30, 2009 at 10:12 AM, Jesse Myers wrote:
>
> I can't say that I agree.
What do you disagree with? Eran said early binding would be addressed in the
security considerations section.
The fact of the matter is that a lot of developers are going to
> encounter OAuth for the first time
> So I guess the proposal is:
>
> oauth_callback in 1st step:
>
> - Present with value - include verifier in callback and require to exchange
> tokens
> - Present with empty value - display verifier to user and require to
> exchange tokens
> - Not included in request - no verifier requirement if al
>
> 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 thread, and I'll say it again:
>
Still not sure we're on the same page with the callback nonce suggestion.
Let me explain again (I'm goin
On Thu, Apr 23, 2009 at 11:43 PM, Manish Pandit wrote:
>
>
>
> On Apr 23, 11:04 pm, Josh Fraser 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 r
On Thu, Apr 23, 2009 at 3:00 PM, Zachary Voase wrote:
>
> 2) The following sentence is a monster: we need to ensure that the
> user who initiated the consumer's request for the request token is the
> same as the one who's authorizing it on the provider. This is a much
> harder problem to solve, be
On Thu, Apr 23, 2009 at 12:03 PM, Brian Eaton wrote:
>
> On Thu, Apr 23, 2009 at 11:54 AM, Mike Malone wrote:
> > In the manual case the user is already typing the request token key
> > manually.
>
> The manual case is not a good user experience, and it isn't nece
On Thu, Apr 23, 2009 at 11:52 AM, Brian Eaton wrote:
>
> On Thu, Apr 23, 2009 at 11:46 AM, Mike Malone wrote:
> > The other difference is that it seems you're not issuing a callback token
> > for the manual case, where there's no callback URL. I think you need a
&
ges 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;
> – Ma
How bout this...
Instead of the provider signing the callback URL, the consumer signs the
redirect to the SP using its consumer and request tokens. This will prevent
an attacker from changing the callback URL, but still allow the consumer to
specify any redirect URL it wants (provided the SP accep
Depending on your use case that may work, but in practice I think loosening
up the constraint requiring timestamps to be monotonically increasing makes
sense. Sometimes it is convenient to generate URIs for later use, and other
requests may be executed between the time such URIs are created and the
;>
>> Great -- just what I was hoping to hear. I didn't want to start
>> implementing if there was a known deal-breaker that I was not seeing.
>> The caveats you mention, while important, are not deal breakers give
>> what we need.
>>
>> --peter
>&
Yea, that would work, some caveats apply though.
First, it sounds like you may not need all of OAuth, but if you want to take
advantage of the existing libraries and whatnot the extra OAuth features
probably won't cause any problems.
As you said, you'll want to generate signed OAuth URIs for the
this topic at
> http://www.hueniverse.com/hueniverse/2009/03/more-thoughts-on-oauth-access-sharing.html
>
>
>
>
>
>
>
> *From:* oauth@googlegroups.com [mailto:oa...@googlegroups.com] *On Behalf
> Of *Mike Malone
> *Sent:* Friday, March 27, 2009 12:57 AM
> *To:* oauth@google
Good post, Eran, but if you removed the token/consumer matching requirement
entirely, and encouraged sharing token credentials, wouldn't we essentially
be in the same boat we're currently in with usernames and passwords? (Ok,
that may be a bit of an exaggeration, but we'd still be giving up a lot o
You can kind of delegate individual requests with OAuth, depending on what
the use case is, by generating a signed URI and handing it off to a fourth
party to use.
In the TweetDeck/TwitPic case, TweetDeck could generate a signed URI for
POSTing the desired tweet, then pass the URI off to TwitPic t
29 matches
Mail list logo
