date:20090423


Do you mean why the callback itself isn't signed? Or the parameter?

EHL

> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Josh Fraser
> Sent: Thursday, April 23, 2009 11:15 PM
> To: OAuth
> Subject: [oauth] What's the back story on why the callback wasn't
> included in the signature?
> 
> 
> 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.
> 

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Manish Pandit

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 registered callback will
> be used, or
>  b) include it, in which case it must be included in the signature

I am still not sure what role the callback is playing in this (maybe
I'm too slow). Per my understanding, even if there was no callback
from the provider to the consumer, this vector would work anyway. The
identity provider has linked the request token with an identity upon
the user's post login confirmation, and any request coming in to
exchange that request token for an access token should be honored as
long as request token does not time out. This timeout too can be at 2
levels. For instance - T1 = request token issued, T2 = request token
associated with an indentity T3 = request token used to an access
token. So the 2 timeouts can be T2-T1 and T3-T2.

Like the folks on earlier posts noted, the timeout does not fix the
issue but reduces the window of vulnerability. I am out of ideas for
now though :(

-cheers,
Manish
--~--~-~--~~~---~--~~
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] What's the back story on why the callback wasn't included in the signature?


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.
--~--~-~--~~~---~--~~
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


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 registered callback will
be used, or
 b) include it, in which case it must be included in the signature




--~--~-~--~~~---~--~~
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 Apr 24, 12:28 am, Luca Mearelli  wrote:
> On Fri, Apr 24, 2009 at 7:15 AM, pkeane  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
> > with the SP, and either ask for or present a PIN, or a pattern or
> > picture to remember, etc., that the user has to verify, either to
> > themselves ("yea that's the same picture I saw") or by typing a short
> > code/PIN to "authenticate."
>
> ...
>
> If I understand what you say, this would not work, since it's the
> attacker that initiates the flow, anything that the consumer shows in
> step A would be known to him so could be possibly used in the social
> part of the attack, making the user to impersonate the attacker in
> step B (e.g. convincing him to input the PIN)

Yes, that's definitely true, but that connection needs to be made
nonetheless, a PIN being a v. weak form of authentication. But
something like "click this link and then when they ask you your
favorite color, say 'red'"  (or somesuch) might be harder to convince
the victim to go for.  I'm probably not the person to suggest the best
mechanism, but I do think  a solution should try to tie u...@a to
u...@b even if there is a "social" element to it (even a banner that
says "you really did come from xyz.com, right?").  It's not any more
intractable than phishing attacks, I believe. If it *is* an attack,
the victim should be made acutely aware of that when they try to
authorize the token.  I am thinking that at this stage, the spec
should maybe provide a range of suggested solutions for this piece,
then maybe someone could propose an extension that address more
airtight A-B authentication.

--peter

>
> Luca
--~--~-~--~~~---~--~~
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

Solving the A-B part is going to be tough.  The internet protocols
just aren't set up to protect against this sort of thing.

You could add the IP address of the requesting user into the
signature, but IP's can always be spoofed.

The consumer app could include an invisible gif that sets a unique
cookie from the provider, but an attacker could simple grab that image
and then redirect victims through a page that includes that image.

It seems to me that this part of the vulnerability is best addressed
through education to users and clear communication on the providers
authentication page.

On Apr 23, 11:28 pm, Luca Mearelli  wrote:
> On Fri, Apr 24, 2009 at 7:15 AM, pkeane  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
> > with the SP, and either ask for or present a PIN, or a pattern or
> > picture to remember, etc., that the user has to verify, either to
> > themselves ("yea that's the same picture I saw") or by typing a short
> > code/PIN to "authenticate."
>
> ...
>
> If I understand what you say, this would not work, since it's the
> attacker that initiates the flow, anything that the consumer shows in
> step A would be known to him so could be possibly used in the social
> part of the attack, making the user to impersonate the attacker in
> step B (e.g. convincing him to input the PIN)
>
> Luca
--~--~-~--~~~---~--~~
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 Fri, Apr 24, 2009 at 7:15 AM, pkeane  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
> with the SP, and either ask for or present a PIN, or a pattern or
> picture to remember, etc., that the user has to verify, either to
> themselves ("yea that's the same picture I saw") or by typing a short
> code/PIN to "authenticate."
...

If I understand what you say, this would not work, since it's the
attacker that initiates the flow, anything that the consumer shows in
step A would be known to him so could be possibly used in the social
part of the attack, making the user to impersonate the attacker in
step B (e.g. convincing him to input the PIN)

Luca

--~--~-~--~~~---~--~~
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 Apr 23, 11:27 pm, Leah Culver  wrote:
> Hi all,
>
> I'd like to keep things as simple as possible for the end user as well as
> the consumer, since consumer applications tend to be less concerned with
> security than service provider applications (and less likely to update their
> apps).
>
> *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.
>
> At the access token endpoint, if the request token has been authorized, then
> an access token is granted. If not, the request token is marked as invalid
> or deleted. This means an attacker would get one shot to exchange the
> request token (unknown if it's authorized or not) for an access token.
> Pretty unlikely chance of success and probably not worth the trouble.
> *
> 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.
>
> This would require a few changes to the spec and would put the burden on the
> service provider instead of users or consumer apps.
>

This seems like a very sensible starting point for a solution.  Good
summary of best approaches & ideas.

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.  Many of the solutions focus on the B-C connection, and
while that approach keeps the user experience good, it does not
adequately address the need for a A-B authentication match. Anything
after B (during which the user indisputably authenticates w/ the SP)
will be as secure as the SP's authentication mechanism (and good
consumer app design) so needn't (I think) be the main focus here.

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.   Whatever happens, I think the consumer is
going to need to signal to the user that it is about to make contact
with the SP, and either ask for or present a PIN, or a pattern or
picture to remember, etc., that the user has to verify, either to
themselves ("yea that's the same picture I saw") or by typing a short
code/PIN to "authenticate."   Surely people are more likely to NOT
complete the steps, but is there really a choice?  Perhaps the spec
should just state the need for this piece (while doing the B-C stuff
which has little effect on UX) and leave it to SP's to decide how to
strengthen the A-B leg (and provide say, a few examples from weakest
to strongest).

--peter keane

> Leah
--~--~-~--~~~---~--~~
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

hi

On Fri, Apr 24, 2009 at 6:27 AM, Leah Culver  wrote:
> 1. One time only token exchange
...
> 2. No callback request parameter
...

these are probably the smallest changes to the spec that can give a
reasonable reduction of the vulnerability window i.e. the time between
the user authorizing the request token and him/her trying to exchange
it for an access token.

I'm not even sure that it's possible to get 'perfect' security given
what the protocol is trying to achieve in a platform that's inherently
stateless (at least not without a *lot* of changes)

The first one may possibly cause some inconvenience to legitimate
users trying to complete the flow before having authorized the token
(e.g. in desktop apps), but this can be mitigated by using the right
wording for the error message to be presented to the user, and it will
help a lot to identify malicious behavior both on the consumer and
service provider side (e.g. setting a cap on the number of repeated
token exchange errors)

Luca

--~--~-~--~~~---~--~~
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


I've been thinking about this for the last couple hours and agree with
Leah and Zach.  The best solution seems to be:

1) Single use tokens that are invalidated if you try to exchange them
a second too early.

2) Either sign the callback parameter or eliminate it altogether.

I'm using OAuth from a javascript widget that will be hosted on
multiple domains.  This makes the variable callback parameter very
attractive to me and other widget developers.  As Zach noted, we can
mitigate the security concerns by simply signing the callback
parameter.  That said, there isn't any reason we can't add forwarding
handlers to enable this functionality as well.  I'm already having to
do this for Yahoo since they don't support callback handlers on non-
registered domains (which makes it funny that Yahoo were so quick to
pull the plug).  While I prefer that we keep the callback parameter, I
understand Leah's desire to get OAuth back up and running ASAP.  Any
major changes to the protocol on the consumer end of things will put
extra burden on a much larger group of developers.

--~--~-~--~~~---~--~~
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: Using Cookie to Thwart Session Fixation


On Thu, Apr 23, 2009 at 7:47 PM, Zhihong  wrote:
>
> Most discussions in the other thread is about protecting callbacks.
> How about if we look at this issue from a different angle? Instead of
> trying to stop session fixation, we find ways to detect it. How about
> if we drop a cookie?
>
> There are many ways to add a cookie. Here is my proposal,
>
> 1. On the redirect to provider for authorization, consumer is required
> to drop a cookieand the content is also the same request token  (e.g
> Set-Cookie: OAUTH_TOKEN=[Request Token]) . This cookie is on consumer
> domain.
> 2. When provider receives the call to authorize token, it's required
> to make a session check call by redirect to consumer. Provider passes
> the request token and a callback as parameters.
> 3. When consumer receives the session check call, it will check the
> cookie. If the token in the cookie matches the parameter, it will call
> the callback to notify provider to proceed. Otherwise, an attack or
> lost cookie is detected. OAuth signing and none can be used for
> security and replay prevention.
> 4. When provider receives the callback from consumer, it knows the
> session is valid and normal OAuth dance continues.
>
> The attacker can ask victim to click on the link but it's very hard to
> drop a cookie on consumer's domain in victim's browser.
>
> The major drawback of this approach is that it practically makes OAuth
> flow 4-legged.
>
> I am sure there are holes ...

The victim is missing the cookie, the attacker has the valid cookie,
because it's the attacker's account at the consumer being linked, not
the victim's.

If the attacker loads the callback URL before the victim does, the
token exchange will succeed.

The scheme you describe is basic XSRF protection against the callback
URL, and consumers should be doing something like this anyway, to
prevent the inverse of the attack we've been worried about this week
(victim's account at consumer is linked to attacker's account at SP).

>
> Zhihong
> >
>

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Leah Culver

Hi all,

I'd like to keep things as simple as possible for the end user as well as
the consumer, since consumer applications tend to be less concerned with
security than service provider applications (and less likely to update their
apps).

*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.

At the access token endpoint, if the request token has been authorized, then
an access token is granted. If not, the request token is marked as invalid
or deleted. This means an attacker would get one shot to exchange the
request token (unknown if it's authorized or not) for an access token.
Pretty unlikely chance of success and probably not worth the trouble.
*
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.

This would require a few changes to the spec and would put the burden on the
service provider instead of users or consumer apps.

Leah

--~--~-~--~~~---~--~~
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: Using Cookie to Thwart Session Fixation

2009-04-23 Thread Peter Saint-Andre


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 4/23/09 8:47 PM, Zhihong wrote:
> Most discussions in the other thread is about protecting callbacks.
> How about if we look at this issue from a different angle? Instead of
> trying to stop session fixation, we find ways to detect it. How about
> if we drop a cookie?

Cookies won't work for anything but HTTP (and even then some HTTP user
agents don't support cookies).

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknxPZ8ACgkQNL8k5A2w/vxBrwCdEqcOC8mwOYMAte82wtB0tWAZ
kewAoPBrhMjWuRSJYkBMRM3AU1fRJgFc
=o15o
-END PGP SIGNATURE-

--~--~-~--~~~---~--~~
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 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, because it means we have to bridge the gap
> between user accounts on the consumer and provider, whilst making any
> solutions feasible for non-HTTP/HTML systems. Unfortunately, at first
> glance, it seems an intractable problem, which cannot be solved
> without a fair amount of work on the user's behalf. This is the real
> 'social engineering' problem; a PIN probably won't work, because if I,
> as a malicious user, can convince someone to authorize a service to
> use their account, then I can probably just give them a PIN and ask
> them to enter it. However, there are still ways of reducing
> uncertainty, which is what any protocol revisions or provider
> recommendations should tackle.

Not sure we're on the same page here. The PIN (or callback nonce, callback
token, or whatever you want to call it) would be generated by the provider,
and the consumer would learn the PIN via a querystring param on the callback
URL (for web apps) or via manual entry by the user (for desktop apps). The
only way an attacker could exploit this scheme would be to convince the
victim to enter the PIN on an unknown site, and we have other mechanisms to
prevent this from happening (browser chrome, certificates, etc).

Mike

--~--~-~--~~~---~--~~
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] Using Cookie to Thwart Session Fixation

2009-04-23 Thread Zhihong


Most discussions in the other thread is about protecting callbacks.
How about if we look at this issue from a different angle? Instead of
trying to stop session fixation, we find ways to detect it. How about
if we drop a cookie?

There are many ways to add a cookie. Here is my proposal,

1. On the redirect to provider for authorization, consumer is required
to drop a cookieand the content is also the same request token  (e.g
Set-Cookie: OAUTH_TOKEN=[Request Token]) . This cookie is on consumer
domain.
2. When provider receives the call to authorize token, it's required
to make a session check call by redirect to consumer. Provider passes
the request token and a callback as parameters.
3. When consumer receives the session check call, it will check the
cookie. If the token in the cookie matches the parameter, it will call
the callback to notify provider to proceed. Otherwise, an attack or
lost cookie is detected. OAuth signing and none can be used for
security and replay prevention.
4. When provider receives the callback from consumer, it knows the
session is valid and normal OAuth dance continues.

The attacker can ask victim to click on the link but it's very hard to
drop a cookie on consumer's domain in victim's browser.

The major drawback of this approach is that it practically makes OAuth
flow 4-legged.

I am sure there are holes ...

Zhihong
--~--~-~--~~~---~--~~
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 Thu, Apr 23, 2009 at 6:43 PM, Dossy Shiobara  wrote:
> 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.

It's totally unsurprising that it's easy to build something insecure
on top of OAuth, desktop or otherwise.  The vulnerability we've been
freaking out about all week means that you basically *can't* build a
secure system on top of it without either doing a lot of things that
aren't even hinted at in the security considerations or changing the
protocol completely.  The goal for any changes we make should be to
make it easy to build a secure system on top of OAuth.  Making it hard
to build something insecure using OAuth isn't anywhere near possible
and it's a waste of time to try to discuss it.

In the case of desktop apps using OAuth, there are a bunch of
(hopefully) blindingly obvious pitfalls - the root of the problem
being that it's inherently impossible for the SP to authenticate that
the consumer is who it claims to be.  This is nothing new, and nothing
we can fix by adding more tokens and requests and signatures.  There
are any number of ideas floating around, all of which are possible to
implement using OAuth 1.0, which still allow you to build something
reasonably secure.  (For example, there are any number of iPhone apps
using a custom URL scheme for their callback URL.)  But these things
don't need to be hardcoded into the spec.

>
> --
> 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 Thu, Apr 23, 2009 at 6:16 PM, Dossy Shiobara  wrote:
> I won't go into those details until a reasonable fix is available.  :-)

The details are on Eran's blog.

>> 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.

Browser bugs: browser bugs are game over for almost everything.

Provider implementation bugs: we should provide better documentation
of what service providers need to get right to prevent these attacks.
I think this is an area we should work very hard to get right in the
revised specification.

> 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.

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.

That's not a good user experience, nor is it necessary to fix the
security problems in the protocol.

--~--~-~--~~~---~--~~
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

2009-04-23 Thread JR Conlin


Brian Eaton wrote:
> There are a few options.
>
> 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.
>
> 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.
>
> 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.
>   
4) The Callback URL is registered with the Provider at the time that the 
Consumer Key and Secret are issued.

This is pretty much what Facebook does and removes the idea of having 
the callback appearing anywhere in the handshake. Yes, it means that you 
can't have pure, dynamically generated URLs. Yes, it means extra work 
and storage for service providers. It also means that the end user 
doesn't have to do anything extra in order to continue using OAuth, 
which should be one of the bigger goals.

I'm pretty sure I'm missing something here, so feel free to chime in why 
this is dumb.

--~--~-~--~~~---~--~~
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 Thu, Apr 23, 2009 at 5:57 PM, Dossy Shiobara  wrote:
> Alice (attacker) and Bob (victim).



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.

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.

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.

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.

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.

--~--~-~--~~~---~--~~
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

2009-04-23 Thread JR Conlin


Mike Malone wrote:
> 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 necessary
> for the vast majority of installed applications:
> https://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
>
> Pownce and several other companies have written iphone, android, and
> blackberry apps that bypass the manual token entry step.
>
>
> Er, right. Sorry. I was thinking of the Netflix style case. You're 
> right, for many Desktop apps manual entry of the request token key is 
> not required.
Netflix doesn't require the end-user to enter a token. The user login 
and confirmation is done via a separate request (something that we get a 
lot of heat about) invoked by the client.

Most of the apps we have register a local handler and then use that as 
the associated callback.

One other thing to note is that the more steps you require the end user 
to perform, the less likely they are to complete the process.

--~--~-~--~~~---~--~~
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

I thought this had been obvious to everyone from day 1 - there's no point in
using a consumer secret at all in a desktop app.  We certainly discussed
this scenario before the first version of the protocol shipped.

On Thu, Apr 23, 2009 at 5:57 PM, Dossy Shiobara  wrote:

>
> 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 Apr 23, 5:00 pm, Zachary Voase  wrote:
> I don't know if I've misunderstood things, but just to clarify - there
> *isn't* an issue of an attacker getting hold of an actual access token
> itself, because the request for the access token is signed with the
> request token secret (which an attacker has no access to).
>
> But basically, I've tried to break down the problem into a couple of
> basic ideas about trust.
>
> 1) We need to make sure that, if present, the oauth_callback parameter
> was generated by the consumer. This can be done easily by including an
> additional parameter oauth_callback_signature with the callback
> parameter signed by the consumer secret and request secret; that's the
> whole point of HMAC. Maybe an additional
> oauth_callback_signature_method parameter could be included with the
> method (i.e. HMAC-SHA1 or HMAC-RSA, etc).
>
> 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, because it means we have to bridge the gap
> between user accounts on the consumer and provider, whilst making any

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

> solutions feasible for non-HTTP/HTML systems. Unfortunately, at first
> glance, it seems an intractable problem, which cannot be solved
> without a fair amount of work on the user's behalf. This is the real
> 'social engineering' problem; a PIN probably won't work, because if I,
> as a malicious user, can convince someone to authorize a service to
> use their account, then I can probably just give them a PIN and ask
> them to enter it. However, there are still ways of reducing

you have a point there (about social engineering attack convincing
victim to enter a PIN).  There must be some other way to store state
in initiating user's brain :).  Really, I think that's what it comes
down to.

> uncertainty, which is what any protocol revisions or provider
> recommendations should tackle.
>
> So how can we ensure that the request token user is the same as the
> authorization user? We can begin by making sure that the request token
> is authorized within a short period of its requesting. This can be
> done purely on the provider side, but where some consumers may wish to
> cache request tokens, this might not be optimal. So a consumer could
> stamp its user authorization URL with a nonce and timestamp, and sign
> it all, enabling the provider to verify that the user auth URL was
> presented within a sensible amount of time. For example:
>
> http://provider.example.com/oauth/authorize?oauth_token=foo&oauth_cal...
>
> So it's a bit of a beast, but it jumps the hurdle of ensuring that
> authorization requests were made within a sensible amount of time. In
> fact, any important parameters in the user auth URL should probably
> also be signed by the consumer. This makes sure that attackers are
> incapable of spoofing authorization parameters (which no doubt is an
> important issue in and of itself).
>
> In addition, as has already been suggested, it could be configured on
> the provider such that when a consumer tries to exchange a request
> token for an access token, if that request fails, the request token is
> put on a blacklist so that it will not be usable again, whether for
> authorization or exchange. In addition, a timeout could be specified
> on the exchange, such that if the exchange is requested a long time
> after the token is authorized, it fails. So what might happen is this:
>
>     * Malicious User (MU) visits consumer site or uses consumer
> desktop app and gets a user auth URL with a request token.
>     * MU gets Ignorant User (IU) to click on user auth URL and
> authorize the third-party application.
>     * If the consumer is a web app, then the user will be redirected
> to the callback URL (which has been signed, so it cannot be spoofed).
> The consumer then gets a request at the callback URL, and tries to
> exchange the request token for an access token. This is successful,
> but one of two things should happen: consumers should either realise
> that the request token was fetched for another user and signal an
> error, or it should associate the new access token with IU instead of
> MU. An alternative behavior would be unacceptable, but there's nothing
> anyone can do to stop evil or ignorant consumer implementations (a
> consumer could, for example, decide to share their entire database of
> access tokens and consumer key/secret pair). Luckily, that's why OAuth
> is good, as access can be revoked.
>     * If the consumer is a desktop app, then a few things might
> happen. MU could sta

[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

Clearly the consumer secret for desktop applications is pointless, but the
existence of the token secret still offers a modicum of protection.  It's
definitely the case that SPs can't reasonably identify to users which
consumer they are giving their data to.

On Thu, Apr 23, 2009 at 5:52 PM, Zachary Voase wrote:

>
> It's not that the malicious software is scanning for access tokens,
> but that the attacker gets the consumer secret for the desktop
> application; this would allow the attacker to exchange request tokens
> for access tokens, etc. (as the attacker has essentially compromised
> the consumer, not the individual users).
>
> On Apr 24, 2:46 am, Brian Eaton  wrote:
> > On Thu, Apr 23, 2009 at 5:35 PM, Dossy Shiobara 
> wrote:
> >
> > > 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.
> >
> > 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?
> >
>

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Zachary Voase


It's not that the malicious software is scanning for access tokens,
but that the attacker gets the consumer secret for the desktop
application; this would allow the attacker to exchange request tokens
for access tokens, etc. (as the attacker has essentially compromised
the consumer, not the individual users).

On Apr 24, 2:46 am, Brian Eaton  wrote:
> On Thu, Apr 23, 2009 at 5:35 PM, Dossy Shiobara  wrote:
>
> > 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.
>
> 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?
--~--~-~--~~~---~--~~
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 Thu, Apr 23, 2009 at 5:35 PM, Dossy Shiobara  wrote:
>
> 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.

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?

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Andrew Badera

On Thu, Apr 23, 2009 at 8:30 PM, Brian Eaton  wrote:

>
> On Thu, Apr 23, 2009 at 3:54 PM, Dossy Shiobara 
> wrote:
> > If the consumer is a desktop app., then the attacker has access to the
> > token secret through application memory inspection.
>
> Malicious software on the user's computer does not need to steal
> access tokens.  It steals passwords, bank account numbers, and
> confidential documents.



All my delicious cookie recipes, gone, gone, gone!

--~--~-~--~~~---~--~~
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 Thu, Apr 23, 2009 at 3:54 PM, Dossy Shiobara  wrote:
> If the consumer is a desktop app., then the attacker has access to the
> token secret through application memory inspection.

Malicious software on the user's computer does not need to steal
access tokens.  It steals passwords, bank account numbers, and
confidential documents.

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Zachary Voase


I think accessing the consumer secret via memory inspection is a very
general problem that goes far beyond just OAuth; it's usually up to
the desktop application developers to make sure they keep the key
secure in memory. 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. With any
protocol, be it FTP, HTTP or even TCP, there's a certain amount of
trust placed in the developers of both the client applications and
server applications. This applies to OAuth as much as it does to
anything else.

On Apr 24, 12:54 am, Dossy Shiobara  wrote:
> 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 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

2009-04-23 Thread Zachary Voase

I don't know if I've misunderstood things, but just to clarify - there
*isn't* an issue of an attacker getting hold of an actual access token
itself, because the request for the access token is signed with the
request token secret (which an attacker has no access to).

But basically, I've tried to break down the problem into a couple of
basic ideas about trust.

1) We need to make sure that, if present, the oauth_callback parameter
was generated by the consumer. This can be done easily by including an
additional parameter oauth_callback_signature with the callback
parameter signed by the consumer secret and request secret; that's the
whole point of HMAC. Maybe an additional
oauth_callback_signature_method parameter could be included with the
method (i.e. HMAC-SHA1 or HMAC-RSA, etc).

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, because it means we have to bridge the gap
between user accounts on the consumer and provider, whilst making any
solutions feasible for non-HTTP/HTML systems. Unfortunately, at first
glance, it seems an intractable problem, which cannot be solved
without a fair amount of work on the user's behalf. This is the real
'social engineering' problem; a PIN probably won't work, because if I,
as a malicious user, can convince someone to authorize a service to
use their account, then I can probably just give them a PIN and ask
them to enter it. However, there are still ways of reducing
uncertainty, which is what any protocol revisions or provider
recommendations should tackle.

So how can we ensure that the request token user is the same as the
authorization user? We can begin by making sure that the request token
is authorized within a short period of its requesting. This can be
done purely on the provider side, but where some consumers may wish to
cache request tokens, this might not be optimal. So a consumer could
stamp its user authorization URL with a nonce and timestamp, and sign
it all, enabling the provider to verify that the user auth URL was
presented within a sensible amount of time. For example:

http://provider.example.com/oauth/authorize?oauth_token=foo&oauth_callback=bar&oauth_timestamp=1010011010&oauth_nonce=4237&oauth_signature=blahblah&oauth_signature_method=HMAC-SHA1

So it's a bit of a beast, but it jumps the hurdle of ensuring that
authorization requests were made within a sensible amount of time. In
fact, any important parameters in the user auth URL should probably
also be signed by the consumer. This makes sure that attackers are
incapable of spoofing authorization parameters (which no doubt is an
important issue in and of itself).

In addition, as has already been suggested, it could be configured on
the provider such that when a consumer tries to exchange a request
token for an access token, if that request fails, the request token is
put on a blacklist so that it will not be usable again, whether for
authorization or exchange. In addition, a timeout could be specified
on the exchange, such that if the exchange is requested a long time
after the token is authorized, it fails. So what might happen is this:

* Malicious User (MU) visits consumer site or uses consumer
desktop app and gets a user auth URL with a request token.
* MU gets Ignorant User (IU) to click on user auth URL and
authorize the third-party application.
* If the consumer is a web app, then the user will be redirected
to the callback URL (which has been signed, so it cannot be spoofed).
The consumer then gets a request at the callback URL, and tries to
exchange the request token for an access token. This is successful,
but one of two things should happen: consumers should either realise
that the request token was fetched for another user and signal an
error, or it should associate the new access token with IU instead of
MU. An alternative behavior would be unacceptable, but there's nothing
anyone can do to stop evil or ignorant consumer implementations (a
consumer could, for example, decide to share their entire database of
access tokens and consumer key/secret pair). Luckily, that's why OAuth
is good, as access can be revoked.
* 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:
1) They would start too early and invalidate the request
token.
2) They would start too late and the request token would time
out.
3) They would ask for an exchange just at the right time and
get access.
The last of these is the dangerous one, but also the least
likely to happen. An exchange timeout of 5 seconds, for example, would
be able to mitigate most attacks; a good idea would be for the
provider to keep the timeout secret to prevent people from getting in
towards the end of the Goldil

[oauth] Re: OAuth Security Advisory


On Thu, Apr 23, 2009 at 12:10 PM, Mike Malone  wrote:
> Er, right. Sorry. I was thinking of the Netflix style case. You're right,
> for many Desktop apps manual entry of the request token key is not required.
>
> I wrote the Pownce iPhone app. It used the web application token exchange
> flow by registering a URI scheme with the iPhone OS, so it doesn't really
> apply here.

Nice work.  It was clever. =)

>> > Asking them to type one more (perhaps 4 digit number) doesn't seem
>> > like such a burden.
>>
>> It's a fine option, but it's not a complete solution.
>
> How's it not a complete solution?

It's not a complete solution because typing a pin is a bad user
experience and is not always necessary.

--~--~-~--~~~---~--~~
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 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 necessary
> for the vast majority of installed applications:
> https://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps
>
> Pownce and several other companies have written iphone, android, and
> blackberry apps that bypass the manual token entry step.
>

Er, right. Sorry. I was thinking of the Netflix style case. You're right,
for many Desktop apps manual entry of the request token key is not required.

I wrote the Pownce iPhone app. It used the web application token exchange
flow by registering a URI scheme with the iPhone OS, so it doesn't really
apply here.


>
> > Asking them to type one more (perhaps 4 digit number) doesn't seem
> > like such a burden.
>
> It's a fine option, but it's not a complete solution.
>

How's it not a complete solution?

Mike

--~--~-~--~~~---~--~~
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 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 necessary
for the vast majority of installed applications:
https://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps

Pownce and several other companies have written iphone, android, and
blackberry apps that bypass the manual token entry step.

> Asking them to type one more (perhaps 4 digit number) doesn't seem
> like such a burden.

It's a fine option, but it's not a complete solution.

--~--~-~--~~~---~--~~
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 Thu, Apr 23, 2009 at 8:54 PM, Mike Malone  wrote:
> In the manual case the user is already typing the request token key
> manually.

This isn't actually required by the spec, and it's something that's
not needed to make the OAuth flow to work, as it's assumed that the
client application already knows the request token, so it suffices to
have a "button" that says: "Authorization completed, proceed"...

Luca

--~--~-~--~~~---~--~~
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

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
> > callback token either way. 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).
>
> This is a terrible user experience.  Some service providers and
> consumers will accept it, but we need good security for installed
> applications even when we can't ask the user to type a PIN manually.


In the manual case the user is already typing the request token key
manually. Asking them to type one more (perhaps 4 digit number) doesn't seem
like such a burden.

Mike

--~--~-~--~~~---~--~~
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: OAuth Security Advisory


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
> callback token either way. 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).

This is a terrible user experience.  Some service providers and
consumers will accept it, but we need good security for installed
applications even when we can't ask the user to type a PIN manually.

--~--~-~--~~~---~--~~
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

Matt, your solution sounds similar. There are two differences, I think.

The first difference is when the callback is sent. Either way works, but
there's slightly less state to maintain if it's sent along during the
redirect vs. the request token request. Is the server-to-server
communication channel necessary if the Consumer -> SP redirect is signed? I
don't think it is...

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
callback token either way. 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).

Mike

On Thu, Apr 23, 2009 at 11:27 AM, Jim Patterson  wrote:

> For consumers that don't support callbacks you can have the user type in
> the token manually.
>
> Here is how we (Yammer) have changed our protocol to close this security
> hole and still allow our API clients to function until a new OAuth spec is
> completed. You can see a diagram of the new authorization flow at the bottom
> of the page.
>
> http://www.yammer.com/api_oauth_security_addendum.html
>
> On Apr 23, 2009, at 11:15 AM, Ryan Kennedy wrote:
>
> A lot of these solutions require something to be passed back by the
> provider in the callback, however callbacks aren't required in OAuth because
> they don't work for non-browser devices. How are you going to pass something
> back to the application when there's no mechanism to do so?
>
> Ryan Kennedy
>
> --
> *From:* Matt Sanford 
> *To:* oauth@googlegroups.com
> *Sent:* Thursday, April 23, 2009 10:31:23 AM
> *Subject:* [oauth] Re: OAuth Security Advisory
>
> 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
>
>
>
> On Apr 23, 2009, at 10:16 AM, Mike Malone wrote:
>
> 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 accepts any callback
> URL).
>
> This reduces the threat to what Eran called a "timing attack" in his blog
> post. There's still a possibility that the attacker could beat the victim
> back to the callback after the request token is authorized. To mitigate
> this, the provider could generate a callback nonce that must be provided
> during the request/access token exchange. This nonce would be appended as a
> querystring param to the callback URL.
>
> I think these two changes eliminate the threat with the smallest change to
> the spec, and without requiring either side to maintain a lot of extra state
> across steps. The SP needs to maintain the callback nonce, but it can be
> stored and expired with the request token.
>
> The drawback is that the manual auth process would require the user to
> enter two numbers at the consumer after authorizing a token: the request
> token key and the callback nonce.
>
> Mike
>
> On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:
>
>>
>> I have a simple idea to propose not as a solution, but hopefully to
>> give someone an idea toward a true solution:
>>
>> What if the callback URL is signed on the provider's end using the
>> consumer's secret key? The drawback is

[oauth] Re: OAuth Security Advisory

2009-04-23 Thread Jim Patterson

For consumers that don't support callbacks you can have the user type  
in the token manually.

Here is how we (Yammer) have changed our protocol to close this  
security hole and still allow our API clients to function until a new  
OAuth spec is completed. You can see a diagram of the new  
authorization flow at the bottom of the page.

http://www.yammer.com/api_oauth_security_addendum.html

On Apr 23, 2009, at 11:15 AM, Ryan Kennedy wrote:

> A lot of these solutions require something to be passed back by the  
> provider in the callback, however callbacks aren't required in OAuth  
> because they don't work for non-browser devices. How are you going  
> to pass something back to the application when there's no mechanism  
> to do so?
>
> Ryan Kennedy
>
> From: Matt Sanford 
> To: oauth@googlegroups.com
> Sent: Thursday, April 23, 2009 10:31:23 AM
> Subject: [oauth] Re: OAuth Security Advisory
>
> 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
>
>
>
> On Apr 23, 2009, at 10:16 AM, Mike Malone wrote:
>
>> 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 accepts any callback URL).
>>
>> This reduces the threat to what Eran called a "timing attack" in  
>> his blog post. There's still a possibility that the attacker could  
>> beat the victim back to the callback after the request token is  
>> authorized. To mitigate this, the provider could generate a  
>> callback nonce that must be provided during the request/access  
>> token exchange. This nonce would be appended as a querystring param  
>> to the callback URL.
>>
>> I think these two changes eliminate the threat with the smallest  
>> change to the spec, and without requiring either side to maintain a  
>> lot of extra state across steps. The SP needs to maintain the  
>> callback nonce, but it can be stored and expired with the request  
>> token.
>>
>> The drawback is that the manual auth process would require the user  
>> to enter two numbers at the consumer after authorizing a token: the  
>> request token key and the callback nonce.
>>
>> Mike
>>
>> On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:
>>
>> I have a simple idea to propose not as a solution, but hopefully to
>> give someone an idea toward a true solution:
>>
>> What if the callback URL is signed on the provider's end using the
>> consumer's secret key? The drawback is it puts the burden on the
>> consumer to close the security hole by checking the signature, and as
>> such the provider has no way of knowing if an application is secure  
>> or
>> not.
>>
>> Shan
>>
>>
>>
>>
>>
>
>
>
>
>
> >


--~--~-~--~~~---~--~~
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

Tell the user to type a pin or something like that.

EHL


On 4/23/09 11:15 AM, "Ryan Kennedy"  wrote:

A lot of these solutions require something to be passed back by the provider in 
the callback, however callbacks aren't required in OAuth because they don't 
work for non-browser devices. How are you going to pass something back to the 
application when there's no mechanism to do so?

Ryan Kennedy


From: Matt Sanford 
To: oauth@googlegroups.com
Sent: Thursday, April 23, 2009 10:31:23 AM
Subject: [oauth] Re: OAuth Security Advisory

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




On Apr 23, 2009, at 10:16 AM, Mike Malone wrote:

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 accepts any callback URL).

This reduces the threat to what Eran called a "timing attack" in his blog post. 
There's still a possibility that the attacker could beat the victim back to the 
callback after the request token is authorized. To mitigate this, the provider 
could generate a callback nonce that must be provided during the request/access 
token exchange. This nonce would be appended as a querystring param to the 
callback URL.

I think these two changes eliminate the threat with the smallest change to the 
spec, and without requiring either side to maintain a lot of extra state across 
steps. The SP needs to maintain the callback nonce, but it can be stored and 
expired with the request token.

The drawback is that the manual auth process would require the user to enter 
two numbers at the consumer after authorizing a token: the request token key 
and the callback nonce.

Mike

 On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:

 I have a simple idea to propose not as a solution, but hopefully to
 give someone an idea toward a true solution:

 What if the callback URL is signed on the provider's end using the
 consumer's secret key? The drawback is it puts the burden on the
 consumer to close the security hole by checking the signature, and as
 such the provider has no way of knowing if an application is secure or
 not.

Shan















--~--~-~--~~~---~--~~
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

2009-04-23 Thread Ryan Kennedy

A lot of these solutions require something to be passed back by the provider in 
the callback, however callbacks aren't required in OAuth because they don't 
work for non-browser devices. How are you going to pass something back to the 
application when there's no mechanism to do so?

Ryan Kennedy





From: Matt Sanford 
To: oauth@googlegroups.com
Sent: Thursday, April 23, 2009 10:31:23 AM
Subject: [oauth] Re: OAuth Security Advisory

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



On Apr 23, 2009, at 10:16 AM, Mike Malone wrote:

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 accepts any callback URL).

This reduces the threat to what Eran called a "timing attack" in his blog post. 
There's still a possibility that the attacker could beat the victim back to the 
callback after the request token is authorized. To mitigate this, the provider 
could generate a callback nonce that must be provided during the request/access 
token exchange. This nonce would be appended as a querystring param to the 
callback URL.

I think these two changes eliminate the threat with the smallest change to the 
spec, and without requiring either side to maintain a lot of extra state across 
steps. The SP needs to maintain the callback nonce, but it can be stored and 
expired with the request token.

The drawback is that the manual auth process would require the user to enter 
two numbers at the consumer after authorizing a token: the request token key 
and the callback nonce.

Mike


On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:


I have a simple idea to propose not as a solution, but hopefully to
give someone an idea toward a true solution:

What if the callback URL is signed on the provider's end using the
consumer's secret key? The drawback is it puts the burden on the
consumer to close the security hole by checking the signature, and as
such the provider has no way of knowing if an application is secure or
not.

Shan









  
--~--~-~--~~~---~--~~
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

2009-04-23 Thread Matt Sanford

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

On Apr 23, 2009, at 10:16 AM, Mike Malone wrote:

> 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 accepts any callback URL).
>
> This reduces the threat to what Eran called a "timing attack" in his  
> blog post. There's still a possibility that the attacker could beat  
> the victim back to the callback after the request token is  
> authorized. To mitigate this, the provider could generate a callback  
> nonce that must be provided during the request/access token  
> exchange. This nonce would be appended as a querystring param to the  
> callback URL.
>
> I think these two changes eliminate the threat with the smallest  
> change to the spec, and without requiring either side to maintain a  
> lot of extra state across steps. The SP needs to maintain the  
> callback nonce, but it can be stored and expired with the request  
> token.
>
> The drawback is that the manual auth process would require the user  
> to enter two numbers at the consumer after authorizing a token: the  
> request token key and the callback nonce.
>
> Mike
>
> On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:
>
> I have a simple idea to propose not as a solution, but hopefully to
> give someone an idea toward a true solution:
>
> What if the callback URL is signed on the provider's end using the
> consumer's secret key? The drawback is it puts the burden on the
> consumer to close the security hole by checking the signature, and as
> such the provider has no way of knowing if an application is secure or
> not.
>
> Shan
>
>
>
> >

--~--~-~--~~~---~--~~
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

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 accepts any callback
URL).

This reduces the threat to what Eran called a "timing attack" in his blog
post. There's still a possibility that the attacker could beat the victim
back to the callback after the request token is authorized. To mitigate
this, the provider could generate a callback nonce that must be provided
during the request/access token exchange. This nonce would be appended as a
querystring param to the callback URL.

I think these two changes eliminate the threat with the smallest change to
the spec, and without requiring either side to maintain a lot of extra state
across steps. The SP needs to maintain the callback nonce, but it can be
stored and expired with the request token.

The drawback is that the manual auth process would require the user to enter
two numbers at the consumer after authorizing a token: the request token key
and the callback nonce.

Mike

On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:

>
> I have a simple idea to propose not as a solution, but hopefully to
> give someone an idea toward a true solution:
>
> What if the callback URL is signed on the provider's end using the
> consumer's secret key? The drawback is it puts the burden on the
> consumer to close the security hole by checking the signature, and as
> such the provider has no way of knowing if an application is secure or
> not.
>
> Shan
> >
>

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Bruno Pedro


On Apr 23, 5:23 pm, pkeane  wrote:

> Does this add the extra burden on the Provider of maintaining state
> between A & C (i.e., being able to "remember" callback from A)?
> Currently, it is the Consumer secret that ties these interactions
> together.  Again it is addressing the need to connect the action/user
> in A with the action/user in C -- to "mix it in" with the out-of-band
> understanding established in the consume secret.

Yes, you're right, but the Provider already needs to maintain some
state regarding the oauth_token that is passed on step C, right?

The problem here, AFAIU, is that the oauth_callback can be forged
somehow tricking the end user. Having the oauth_callback being sent
behind the scenes will remove this problem once and for all.

The oauth_challenge proposal is a simple way of tying together (from
the Consumer perspective) interactions.
--~--~-~--~~~---~--~~
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 Apr 23, 10:50 am, Paul Lindner  wrote:
> Hi Luca,
>
> In the past few days we have discussed some of the options you mention  
> below.  I even created some prototypes for the 3-legged OAuth  
> implementation in shindig to test them out.   Note that these  
> proposals only mitigate the problem, they do not solve it.  They do  
> add useful features and I hope that we can discuss their merits and  
> either add them as extensions or incorporate them into the base  
> protocol.
>
> -
>
> I have two changes to the protocol, the first, which has been  
> previously mentioned, I propose be named "Strong Callbacks."    To  
> implement strong callbacks the consumer must send an oauth_callback  
> parameter when obtaining a request token.
>
> The provider can then take the following actions:
>
> 1. callback URL specified for request token, callback URL specified  
> for authorization
>
> FAIL the request and send email to the security team.  A third party  
> is trying to inject a callback URL.
>
> 2. callback URL not specified for request token, is specified for  
> authorization
>
> Equivalent to existing OAuth protocol
>
> Generate "scary warning" for the user that the consumer wants to  
> redirect, but don't actually do it.  Display the URL and help the user  
> choose whether they want to redirect or not.
>
> This does not solve the problem, it only mitigates it somewhat.  If a  
> consumer uses predictable callback URLs then the attacker can still  
> carry out the attack, it's just more difficult -- the attacker may  
> have to set up a proxy to the authorization flow so they can intercept  
> the browser->service provider flow or hit the URL with proper timing.
>
> -
> 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 callback URL then an attacker can gain  
> access without the end user even knowing about it. (see the flowchart  
> at twitter to understand how this can be dangerous:  
> http://apiwiki.twitter.com/Sign-in-with-Twitter)
>

I think this is exactly right -- access is to entire consumer key (not
so good).  But one needn't go so far as "identifying" the user, rather
the provider needs a way to confirm that the initial request (A) can
be tied to the "authorize token" request (C) -- by connecting it to
user (even if this "user" only exists for this one transaction -- thus
my thought of a PIN), or by some other means such as a "challenge."
It'd be nice to add it into the consumer secret (and include
combunation in URL) so the provider need not maintain state between
requests.  Seems like the two options are for the user to self-
identify (e.g., PIN, an "is this you?" prompt, etc.) upon
authorization request OR have the provider maintain state between A &
C.

--peter

> Instead of this blanket authorization we want to grant access to a  
> specific USER/CONSUMER combination.    For an analogy look at the  
> mysql grant command.  The current OAuth authorization pattern is  
> similar to this:
>
>    GRANT ALL ON localuser.* TO ''@'remoteconsumer';
>
> You grant access to a consumer, not to a consumer/user pair.  Instead  
> we want the equivalent of this:
>
>    GRANT ALL ON localuser.* TO 'remoteuser'@'remoteconsumer'
>
> Remote user may mean different things depending on the consumer.  For  
> web sites this could be a profile URL which, when fetched reveals the  
> users name/thumbnail url etc.  I suggest leveraging microformats and/
> or link rel tags.  Sites without the concept of a user may have to use  
> some other identifier.
>
> For mobile or desktop clients, things are less clear.  Perhaps simple  
> user identifiable information is sufficient.  A delegated identity  
> might be required.
>
> To pass this information a consumer can send the identifying  
> information via an 'oauth_initiating_user' parameter when obtaining a  
> request token.
>
> In either case we now have remote user information *and* consumer  
> information.  The authorization screen will include this information,  
> along with a "That's not Me!" button.
>
> This doesn't stop all lines of attack -- an attacker could set up  
> cloned profiles that "look" like the remote user and attempt to get  
> the user to authorize.
>
> There's also a privacy issue.  Perhaps the user does not want to share  
> identifying information with the consumer. However...  As a provider  
> I'm very interested in binding accounts in the reverse direction,  
> especially partners where I have a bilateral agreement in place.  
> (Again, this might not be something that end-user desires...)
>
> On Apr 23, 2009, at 7:11 AM, Luca Mearelli wrote:
>
>
>
> > first of all, my sincere thanks to all those involved in this for how
> > it has been managed!
>
> > Since reading the advisory and th

[oauth] Re: OAuth Security Advisory

2009-04-23 Thread Breno de Medeiros

We have thought about it and decided it was a bad idea, because:

1. If the consumer uses RSA keys, then the provider cannot sign using them.

2. If the consumer uses HMAC keys, then the provider would be signing
using the same key. It is generally consider a bad idea in
cryptographic protocols to have two different parties use the same key
for the same purpose (e.g., sign). It allows for a class of attacks
called reflection attacks.

On Thu, Apr 23, 2009 at 9:25 AM, Shan  wrote:
> What if the callback URL is signed on the provider's end using the
> consumer's secret key? The drawback is it puts the burden on the
> consumer to close the security hole by checking the signature, and as
> such the provider has no way of knowing if an application is secure or
> not.

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Breno de Medeiros


Not necessarily. The provider builds the request_token, so it could
simply include the callback_url in the request_token. If it does so,
it must authenticate it (e.g., HMAC with a key known _only_ to the
provider) so that an attacker cannot tamper and modify it.

On Thu, Apr 23, 2009 at 9:23 AM, pkeane  wrote:
> Does this add the extra burden on the Provider of maintaining state
> between A & C (i.e., being able to "remember" callback from A)?
> Currently, it is the Consumer secret that ties these interactions
> together.  Again it is addressing the need to connect the action/user
> in A with the action/user in C -- to "mix it in" with the out-of-band
> understanding established in the consume secret.



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--~--~-~--~~~---~--~~
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

2009-04-23 Thread Shan


I have a simple idea to propose not as a solution, but hopefully to
give someone an idea toward a true solution:

What if the callback URL is signed on the provider's end using the
consumer's secret key? The drawback is it puts the burden on the
consumer to close the security hole by checking the signature, and as
such the provider has no way of knowing if an application is secure or
not.

Shan
--~--~-~--~~~---~--~~
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 Apr 23, 11:05 am, Bruno Pedro  wrote:
> Hi,
>
> We (tarpipe) have been thinking about the problem for a while and we
> think we have a solution.
>
> So, here's our proposed solution (against OAuth Core 1.0 
> —http://oauth.net/core/1.0):
>
> 1- In §6 (OAuth Authentication Flow diagram), add two optional
> parameters to step A (Consumer Request Request Token) preventing the
> man-in-the-middle attack when used together: oauth_callbak and
> oauth_challenge;
>
> 1.a- The oauth_challenge should be saved on the Consumer side and
> associated with the user initiating the request — by using session
> storage, for instance;
>
> 2- In §6 (OAuth Authentication Flow diagram), add one optional
> parameter to step D (Service Provider Directs User to Consumer)
> preventing the man-in-the-middle attack: oauth_challenge;
>
> 3- The Consumer, instead of providing the oauth_callback on step C,
> provides it on step A along with an optional oauth_challenge which
> should be saved on both the Consumer and Provider applications;
>
> 4- The Provider, instead of relying on the oauth_callback from step C,
> will rely on the one coming from step A and will redirect the user to
> that URL using an optional oauth_challenge GET parameter if one was
> provided on step A;

Does this add the extra burden on the Provider of maintaining state
between A & C (i.e., being able to "remember" callback from A)?
Currently, it is the Consumer secret that ties these interactions
together.  Again it is addressing the need to connect the action/user
in A with the action/user in C -- to "mix it in" with the out-of-band
understanding established in the consume secret.

>
> 5- The Consumer will then check the oauth_challenge that comes from
> the redirect on step D against the one previously provided on step A
> and will only complete the transaction if both values match;
>
> 6- The Consumer will immediately destroy the oauth_challenge on its
> side, preventing future requests coming to the same URL.
>
> Advantages:
>
> a- It's impossible to create a man-in-the-middle attack by forging the
> oauth_callback parameter because it's being sent behind the scenes on
> step A and the Provider doesn't rely on the one being sent on step C;
>
> b- It's also possible to detect such attacks by checking if the
> oauth_callback parameter is being sent on step C and if it's different
> from the one on step A — the attacker won't know if the Consumer is
> sending the oauth_callback on step A and will try to forge it on step
> C;
>
> c- It's impossible for the attacker to keep trying to finish the
> authorization process on the Consumer side (steps D and eventually E)
> because he/she needs access to the oauth_challenge that was provided
> behind the scenes on step A.
>
> We hope it helps getting to a solution. Let me know about it.
>
> Best,
> Bruno Pedro
--~--~-~--~~~---~--~~
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

2009-04-23 Thread Paul Lindner

Hi Luca,

In the past few days we have discussed some of the options you mention  
below.  I even created some prototypes for the 3-legged OAuth  
implementation in shindig to test them out.   Note that these  
proposals only mitigate the problem, they do not solve it.  They do  
add useful features and I hope that we can discuss their merits and  
either add them as extensions or incorporate them into the base  
protocol.

-

I have two changes to the protocol, the first, which has been  
previously mentioned, I propose be named "Strong Callbacks."To  
implement strong callbacks the consumer must send an oauth_callback  
parameter when obtaining a request token.

The provider can then take the following actions:

1. callback URL specified for request token, callback URL specified  
for authorization

FAIL the request and send email to the security team.  A third party  
is trying to inject a callback URL.

2. callback URL not specified for request token, is specified for  
authorization

Equivalent to existing OAuth protocol

Generate "scary warning" for the user that the consumer wants to  
redirect, but don't actually do it.  Display the URL and help the user  
choose whether they want to redirect or not.

This does not solve the problem, it only mitigates it somewhat.  If a  
consumer uses predictable callback URLs then the attacker can still  
carry out the attack, it's just more difficult -- the attacker may  
have to set up a proxy to the authorization flow so they can intercept  
the browser->service provider flow or hit the URL with proper timing.

-
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 callback URL then an attacker can gain  
access without the end user even knowing about it. (see the flowchart  
at twitter to understand how this can be dangerous:  
http://apiwiki.twitter.com/Sign-in-with-Twitter)

Instead of this blanket authorization we want to grant access to a  
specific USER/CONSUMER combination.For an analogy look at the  
mysql grant command.  The current OAuth authorization pattern is  
similar to this:

   GRANT ALL ON localuser.* TO ''@'remoteconsumer';

You grant access to a consumer, not to a consumer/user pair.  Instead  
we want the equivalent of this:

   GRANT ALL ON localuser.* TO 'remoteuser'@'remoteconsumer'

Remote user may mean different things depending on the consumer.  For  
web sites this could be a profile URL which, when fetched reveals the  
users name/thumbnail url etc.  I suggest leveraging microformats and/ 
or link rel tags.  Sites without the concept of a user may have to use  
some other identifier.

For mobile or desktop clients, things are less clear.  Perhaps simple  
user identifiable information is sufficient.  A delegated identity  
might be required.

To pass this information a consumer can send the identifying  
information via an 'oauth_initiating_user' parameter when obtaining a  
request token.

In either case we now have remote user information *and* consumer  
information.  The authorization screen will include this information,  
along with a "That's not Me!" button.

This doesn't stop all lines of attack -- an attacker could set up  
cloned profiles that "look" like the remote user and attempt to get  
the user to authorize.

There's also a privacy issue.  Perhaps the user does not want to share  
identifying information with the consumer. However...  As a provider  
I'm very interested in binding accounts in the reverse direction,  
especially partners where I have a bilateral agreement in place.   
(Again, this might not be something that end-user desires...)

On Apr 23, 2009, at 7:11 AM, Luca Mearelli wrote:

>
> first of all, my sincere thanks to all those involved in this for how
> it has been managed!
>
> Since reading the advisory and the post an Eran's blog, I kept
> ruminating about the issue, here are a few thoughts:
>
> To solve the problem we'd need a way to make it impossible (or at
> least very hard) for the attacker to get an access token from the
> request token authorized by the real service provider user.
>
> Since the attacker knows the request token (he has generated it) we
> need some information to be passed around that the service might use
> to verify that the request token is being exchanged with the access
> token by the same user that authorized it.
>
> It could be some token (or signature) that the service provider
> generates before sending the user back to the consumer to complete the
> request and that should be passed to the service provider upon token
> exchange. I guess that this is more or less what Eran said in the
> blog: "an unpredictable callback parameter generated at the Service
> Provider to the callback URI on return".
>
> But if we do so we also n

[oauth] Re: OAuth Security Advisory

2009-04-23 Thread Bruno Pedro


Hi,

We (tarpipe) have been thinking about the problem for a while and we
think we have a solution.

So, here's our proposed solution (against OAuth Core 1.0 —
http://oauth.net/core/1.0):

1- In §6 (OAuth Authentication Flow diagram), add two optional
parameters to step A (Consumer Request Request Token) preventing the
man-in-the-middle attack when used together: oauth_callbak and
oauth_challenge;

1.a- The oauth_challenge should be saved on the Consumer side and
associated with the user initiating the request — by using session
storage, for instance;

2- In §6 (OAuth Authentication Flow diagram), add one optional
parameter to step D (Service Provider Directs User to Consumer)
preventing the man-in-the-middle attack: oauth_challenge;

3- The Consumer, instead of providing the oauth_callback on step C,
provides it on step A along with an optional oauth_challenge which
should be saved on both the Consumer and Provider applications;

4- The Provider, instead of relying on the oauth_callback from step C,
will rely on the one coming from step A and will redirect the user to
that URL using an optional oauth_challenge GET parameter if one was
provided on step A;

5- The Consumer will then check the oauth_challenge that comes from
the redirect on step D against the one previously provided on step A
and will only complete the transaction if both values match;

6- The Consumer will immediately destroy the oauth_challenge on its
side, preventing future requests coming to the same URL.


Advantages:

a- It's impossible to create a man-in-the-middle attack by forging the
oauth_callback parameter because it's being sent behind the scenes on
step A and the Provider doesn't rely on the one being sent on step C;

b- It's also possible to detect such attacks by checking if the
oauth_callback parameter is being sent on step C and if it's different
from the one on step A — the attacker won't know if the Consumer is
sending the oauth_callback on step A and will try to forge it on step
C;

c- It's impossible for the attacker to keep trying to finish the
authorization process on the Consumer side (steps D and eventually E)
because he/she needs access to the oauth_challenge that was provided
behind the scenes on step A.


We hope it helps getting to a solution. Let me know about it.


Best,
Bruno Pedro
--~--~-~--~~~---~--~~
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

My thoughts as a decidedly non-expert OAuth user (I have a consumer on
App Engine that'll access a GMail acct):

The consumer key & secret provide the out-of-band "understanding"
between the consumer and service provider.  The attacker exploits that
trust since the actual "user" does not enter into the mix when an
OAuth handshake begins (consumer asks for unauthorized request token).
 Seems there is no fix that does not connect the human user to that
initial request and verifies that human upon authorization. In ER
terms, there is a many-to-many between consumer and service.  That
many-to-many is resolved in a "bridge" that includes user. Any
interaction that "queries" the relationship based on the
Consumer<->Service out-of-band agreement absent user identification
will be vulnerable.  Does that sound right?

My bank uses a PIN number as an extra layer, and maybe it could
provide the lynchpin here?.  An initial request asks user to enter a
PIN.  That PIN is "mixed in" to the request token secret (just like
the consumer secret is mixed in).  When the user gets directed to the
service to authorize, they are required to enter their PIN.
(Obviously, the SP will check that the entered PIN is correct -- no
"state" necessary since it's encrypted into the secret).  If they do
not have it or get it wrong, auth request is rejected.  User can
easily go back to Consumer and start again.

Sorry if that's way off base -- just my initial take...

--peter keane

On Apr 23, 2:41 am, Eran Hammer-Lahav  wrote:
> The OAuth Security Advisory 2009.1 was posted on the OAuth site:
>
> http://oauth.net/advisories/2009-1
>
> For more information on the attack:
>
> http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses...
>
> No information has been withheld. The issue is now fully public.
>
> EHL
--~--~-~--~~~---~--~~
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

2009-04-23 Thread Breno

On Thu, Apr 23, 2009 at 7:11 AM, Luca Mearelli wrote:

>
> first of all, my sincere thanks to all those involved in this for how
> it has been managed!
>
> Since reading the advisory and the post an Eran's blog, I kept
> ruminating about the issue, here are a few thoughts:
>
> To solve the problem we'd need a way to make it impossible (or at
> least very hard) for the attacker to get an access token from the
> request token authorized by the real service provider user.
>
> Since the attacker knows the request token (he has generated it) we
> need some information to be passed around that the service might use
> to verify that the request token is being exchanged with the access
> token by the same user that authorized it.
>
> It could be some token (or signature) that the service provider
> generates before sending the user back to the consumer to complete the
> request and that should be passed to the service provider upon token
> exchange. I guess that this is more or less what Eran said in the
> blog: "an unpredictable callback parameter generated at the Service
> Provider to the callback URI on return".
>
> But if we do so we also need to make sure that the callback URL is NOT
> taken from the parameters passed in the redirect to the service
> provider that the user follows when authorizing (step 6.2.1 of the
> spec) or at least that it is "vetted" (allowing only those within a
> specific domain).


Allowing callbacks only within a specific domain is not a sufficient
security mechanism for most web sites. It assumes that the website does not
have any URL which is an open redirector, as you mention below.




>
> If the Service provider accepts any redirect then any information that
> it want to pass back to the  consumer might be intercepted by the
> attacker (via a callback that goes through an attacker controller
> host).


It also assumes that the site does not provide interfaces for the attacker
to create image links that can cause leakage of the parameter via referer
header.


>
> Another option to make sure the SP can pass information to the
> consumer would be to add the oauth_callback parameter to the request
> token request (step 6.1.1) and use that callback when the request
> token is exchanged for the access token (this parameter should be
> generated by the consumer site and not know to the user or the
> attacker until the redirect).


I believe this would be a much more robust way to protect the secrecy of any
oauth_callback parameter.


>


>
> A last thing that might mitigate social engineering attacks could be
> to require the consumer to pass to the service provider some
> information about who their user who is requesting the request token
> is, then the service provider could show this infos to the user trying
> to authorize the request token (e.g. the SP may say: "you are going to
> authorize the user Xyz at the service Abc access to your data").
>
> what do you think?
>
> ...just my 2c
> Luca
>
> >
>


-- 
Breno de Medeiros

--~--~-~--~~~---~--~~
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


first of all, my sincere thanks to all those involved in this for how
it has been managed!

Since reading the advisory and the post an Eran's blog, I kept
ruminating about the issue, here are a few thoughts:

To solve the problem we'd need a way to make it impossible (or at
least very hard) for the attacker to get an access token from the
request token authorized by the real service provider user.

Since the attacker knows the request token (he has generated it) we
need some information to be passed around that the service might use
to verify that the request token is being exchanged with the access
token by the same user that authorized it.

It could be some token (or signature) that the service provider
generates before sending the user back to the consumer to complete the
request and that should be passed to the service provider upon token
exchange. I guess that this is more or less what Eran said in the
blog: "an unpredictable callback parameter generated at the Service
Provider to the callback URI on return".

But if we do so we also need to make sure that the callback URL is NOT
taken from the parameters passed in the redirect to the service
provider that the user follows when authorizing (step 6.2.1 of the
spec) or at least that it is "vetted" (allowing only those within a
specific domain).
If the Service provider accepts any redirect then any information that
it want to pass back to the  consumer might be intercepted by the
attacker (via a callback that goes through an attacker controller
host).
Another option to make sure the SP can pass information to the
consumer would be to add the oauth_callback parameter to the request
token request (step 6.1.1) and use that callback when the request
token is exchanged for the access token (this parameter should be
generated by the consumer site and not know to the user or the
attacker until the redirect).

A last thing that might mitigate social engineering attacks could be
to require the consumer to pass to the service provider some
information about who their user who is requesting the request token
is, then the service provider could show this infos to the user trying
to authorize the request token (e.g. the SP may say: "you are going to
authorize the user Xyz at the service Abc access to your data").

what do you think?

...just my 2c
Luca

--~--~-~--~~~---~--~~
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] OAuth Security Advisory


The OAuth Security Advisory 2009.1 was posted on the OAuth site:

http://oauth.net/advisories/2009-1

For more information on the attack:

http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html

No information has been withheld. The issue is now fully public.

EHL

--~--~-~--~~~---~--~~
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: Can OAuth be used to login to a consumer website?