Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Joseph Cheek]

nor can oauth assure the provider that a desktop app is legitimate when
the app authenticates itself to the provider.

John Kristian wrote:
> An OAuth Consumer that's deployed to users' desktops or mobile devices
> can't keep a secret. One should assume its consumer key and consumer
> secret will be known to attackers. Consequently, OAuth doesn't really
> assure the user that he's authorizing a legitimate copy of the
> Consumer software.

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[John Kristian]

This issue has been discussed at http://groups.google.com/group/oauth?hl=en
You might might find that informative.  Some highlights:

An OAuth Consumer that's deployed to users' desktops or mobile devices
can't keep a secret. One should assume its consumer key and consumer
secret will be known to attackers. Consequently, OAuth doesn't really
assure the user that he's authorizing a legitimate copy of the
Consumer software. (There are other ways to assure this; for example
the user might trust Apple's app store.)

Such a Consumer should avoid revealing a user's token secrets to other
users or other applications on the same platform. I've heard that the
iPhone Keychain is useful for this purpose. There's no need to hide
token secrets from their user (although the user should be discouraged
from revealing his token secrets to other users).

OAuth provides some value in this situation. It enables the Consumer
to avoid storing the user's password, and avoid transmitting the
password with each request to the Service Provider. (Instead, it
stores an access token secret, and signs each request.) It enables the
Service Provider to revoke permission for each Consumer individually,
without changing the password.

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Jason Martin]

I'm sorry, I was talking about distributing source code. However, I  
wasn't thinking of Open Source (even though I wrote that), I was  
thinking of things like interpreted languages (like PHP) where you  
would distribute an application that can't be compiled in to a binary,  
as, even if you don't release the project as open source, if you can  
download, you have the source code. For example, there is a PHP  
project out there called eyeOS, which does what it sounds like it  
does: creates an Operating System like application that runs in your  
browser. If I were to write a Twitter client for that using OAuth, and  
put that up for download for a user to install, even though I am not  
making it open source, I am still releasing the source code because I  
cannot compile the code into a binary. What would you suggest I do,  
then, to try to hide my consumer key and secret to prevent people from  
using it to spam twitter and (possibly) getting my app shut down?

  - Jason

On Aug 17, 2009, at 4:55 PM, Chris Babcock wrote:

>
> Silly me. I thought someone was talking about distributing source  
> code.
> Building an enduser distribution is somewhat to entirely different.
>
> First, there really isn't any point to using OAuth for a client unless
> the client code lives on the network. The whole advantage of the  
> scheme
> is that the user does not have to disclose credentials to one or more
> third parties. An application that doesn't access a third party  
> network
> should use basic authentication over HTTPS.
>
> If Twitter decides to eliminate basic auth then the correct way  
> (from a
> security stand point) to implement OAuth would be to obtain a separate
> key for each client. I don't see the current OAuth spec as being set  
> up
> to handle bulk key assignments, but you can't distribute a single  
> key to
> multiple clients outside of your network. Whether or not the app is
> Open Source is a non-issue; It's complete FUD-rucking to imply that it
> is any diffent distributing a secret key in a close source app than it
> would be to do so in an open source app.
>
> What happens if you try to use a screwdriver as a hammer? It's the  
> same
> thing here only someone had to drag Open Source into as if that made
> any kind of a difference. To top it off, the OP had a complete
> misunderstanding of the consequences of key disclosure. "A Spammer
> could use it and get your app banned..." as if that's of any
> consequence compared to the users' accounts getting hijacked by apps
> impersonating your client.
>
> And what's with keeping score as if Open Auth and basic were a couple
> of talking tools on Disney Channel having some sort of ludicrous
> rivalry?
>
> Chris Babcock
>
>
>> This is interesting Chris, as I have had the same question.  How  
>> would
>> you propose to distribute a usable FLOSS twitter app that uses Oauth
>> to authenticate itself but doesn't include the app's consumer key and
>> consumer secret?  fetch the key and secret at runtime from a secure
>> server somewhere?  that could be trivially intercepted.
>>
>> Joseph Cheek
>> @cheekdotcom
>>
>> Chris Babcock wrote:
>>> On Sun, 16 Aug 2009 18:49:49 -0400
>>> Jason Martin  wrote:
>>>
>>>
 On another note, how "Open Source friendly" is OAuth? I'm not sure
 if people who write open source software want to be giving out
 their Consumer Secret key in their source code

>>>
>>> Reasoning from a faulty premise.
>>>
>>> When you know your code is going to be seen you either avoid doing
>>> stupid things like hard coding credentials or you learn fast that
>>> configuration data is not code.
>>>
>>> (Now where I did leave my virtual haddock?)
>>>
>>> Chris Babcock

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[srikanth reddy]

I still didnt get this
Just to make my question clear
How are you going to obtain tokens for *other *users using the application
itself?
The worst you can do is use the key/secrets to trap *new *users by building
a brand new app
(with the stolen consumer key/secrets. And new clients have to trust this
app before downloading)
I am just trying to understand why this approach(of getting consumer
secrets/tokens from  a server which changes the values periodically)is worse
than storing the keys at the client itself.

<>

Agreed on this part.

<>

This is not clear. Sending what kind of requests? User will only approve the
requests coming directly from twitter . But before that twitter will verify
the app credentials (which will pass as they are stoled ones). But the user
will have to trust this app even before he starts using (by downloading that
app he shows some level of trust).

Just need clarification on this statement
"You don't even have to intercept the key, just
  use the *application itself  *to obtain tokens for other users' accounts"


On Tue, Aug 18, 2009 at 3:08 AM, Chris Babcock wrote:

>
> On Tue, 18 Aug 2009 02:52:24 +0530
> srikanth reddy  wrote:
>
> > <<
> > It's worse than that. You don't even have to intercept the key, just
> > use the application itself to obtain tokens for other users' accounts.
> > How are they going to tell the difference between their copy of TweetX
> > and someone elses' in their auth dialogs?>>
> >
> > Sorry. I didn't get this. How are you going to obtain tokens for
> > *other * users?
>
> It's a social engineering attack.
>
> If the app contains code to authorize new accounts and all the copies
> of the app use the same secret key then Twitter will not be able to
> tell the difference between a legitimate token request and a spoofed
> request. Send out enough requests and eventually a user will approve
> your token giving you complete access to their account.
>
> Chris Babcock
>
>
>

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Bill Kocik]

On Aug 17, 4:55 pm, Chris Babcock  wrote:
> Silly me. I thought someone was talking about distributing source code.
> Building an enduser distribution is somewhat to entirely different.

That's what I was getting at when I said "a desktop or mobile device
application - open source or closed". I think you're seeing the same
challenge now that many of the rest of us are. Distributing an OSS
server-side app is a cinch; as you said, you put "Go get yourself some
Twitter OAuth credentials" in the README for developers who are using
your code as the basis for their app. The hard part is distributing an
end-user ready desktop app.

OAuth's out-of-band auth flow is intended to solve this for non-
browser based applications, but I think how the developer of such an
app protects their client credentials was sort of "left as an exercise
for the reader". The trouble is, it's pretty much impossible. The
problem we were left to solve appears unsolvable.

This means someone has to go back to the drawing board. This is a
really big, fatal flaw in OAuth that's going to have to be fixed
somehow.

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Chris Babcock]

On Tue, 18 Aug 2009 02:52:24 +0530
srikanth reddy  wrote:

> <<
> It's worse than that. You don't even have to intercept the key, just
> use the application itself to obtain tokens for other users' accounts.
> How are they going to tell the difference between their copy of TweetX
> and someone elses' in their auth dialogs?>>
> 
> Sorry. I didn't get this. How are you going to obtain tokens for
> *other * users?

It's a social engineering attack.

If the app contains code to authorize new accounts and all the copies
of the app use the same secret key then Twitter will not be able to
tell the difference between a legitimate token request and a spoofed
request. Send out enough requests and eventually a user will approve
your token giving you complete access to their account.

Chris Babcock

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[srikanth reddy]

<<
It's worse than that. You don't even have to intercept the key, just
use the application itself to obtain tokens for other users' accounts.
How are they going to tell the difference between their copy of TweetX
and someone elses' in their auth dialogs?>>

Sorry. I didn't get this. How are you going to obtain tokens for *other *
users?
The worst you can do is use the key/secrets to trap *new *users. Even if you
assume the app
is storing tokens locally, it does only for that desktop user.True there is
a risk if some one steals his access tokens but he is not completely wiped
out as he still has the option of revoking the access to the app.

Srikanth

On Tue, Aug 18, 2009 at 2:39 AM, Chris Babcock wrote:

>
> On Mon, 17 Aug 2009 23:32:58 +0530
> srikanth reddy  wrote:
>
> > @chris
> > You cannot ask every user to get new consumer token/secret.
> > There is no way you can protect a consumer secret.
>
> I did have a blind spot operating here. When someone says, "Open
> Source," I'm usually thinking server software not Joe's ShareWare.
> Since we were talking about source code distribution, I wasn't even
> thinking about user binaries.
>
> > @Joseph
> > < > server somewhere?  that could be trivially intercepted.>>
> > As far as i know this is the best way to hide the consumer secret.
> > This will not stop a determined user who try to intercept the keys
> > but you have the option of changing your key/secret values( for a
> > consumer) periodically. Other options are obfuscating/encrypting
> > secrets at client side (again it will not stop a determined user).
> > But the key management is difficult here as you have to download the
> > app everytime(or whenever the risk of keys being compromised is high)
>
> It's worse than that. You don't even have to intercept the key, just
> use the application itself to obtain tokens for other users' accounts.
> How are they going to tell the difference between their copy of TweetX
> and someone elses' in their auth dialogs?
>
> Chris Babcock
>
>

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Chris Babcock]

On Mon, 17 Aug 2009 23:32:58 +0530
srikanth reddy  wrote:

> @chris
> You cannot ask every user to get new consumer token/secret.
> There is no way you can protect a consumer secret.

I did have a blind spot operating here. When someone says, "Open
Source," I'm usually thinking server software not Joe's ShareWare.
Since we were talking about source code distribution, I wasn't even
thinking about user binaries.

> @Joseph
> < server somewhere?  that could be trivially intercepted.>>
> As far as i know this is the best way to hide the consumer secret.
> This will not stop a determined user who try to intercept the keys
> but you have the option of changing your key/secret values( for a
> consumer) periodically. Other options are obfuscating/encrypting
> secrets at client side (again it will not stop a determined user).
> But the key management is difficult here as you have to download the
> app everytime(or whenever the risk of keys being compromised is high)

It's worse than that. You don't even have to intercept the key, just
use the application itself to obtain tokens for other users' accounts.
How are they going to tell the difference between their copy of TweetX
and someone elses' in their auth dialogs?

Chris Babcock

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Chris Babcock]

Silly me. I thought someone was talking about distributing source code.
Building an enduser distribution is somewhat to entirely different.

First, there really isn't any point to using OAuth for a client unless
the client code lives on the network. The whole advantage of the scheme
is that the user does not have to disclose credentials to one or more
third parties. An application that doesn't access a third party network
should use basic authentication over HTTPS.

If Twitter decides to eliminate basic auth then the correct way (from a
security stand point) to implement OAuth would be to obtain a separate
key for each client. I don't see the current OAuth spec as being set up
to handle bulk key assignments, but you can't distribute a single key to
multiple clients outside of your network. Whether or not the app is
Open Source is a non-issue; It's complete FUD-rucking to imply that it
is any diffent distributing a secret key in a close source app than it
would be to do so in an open source app.

What happens if you try to use a screwdriver as a hammer? It's the same
thing here only someone had to drag Open Source into as if that made
any kind of a difference. To top it off, the OP had a complete
misunderstanding of the consequences of key disclosure. "A Spammer
could use it and get your app banned..." as if that's of any
consequence compared to the users' accounts getting hijacked by apps
impersonating your client.

And what's with keeping score as if Open Auth and basic were a couple
of talking tools on Disney Channel having some sort of ludicrous
rivalry?

Chris Babcock
 

> This is interesting Chris, as I have had the same question.  How would
> you propose to distribute a usable FLOSS twitter app that uses Oauth
> to authenticate itself but doesn't include the app's consumer key and
> consumer secret?  fetch the key and secret at runtime from a secure
> server somewhere?  that could be trivially intercepted.
> 
> Joseph Cheek
> @cheekdotcom
> 
> Chris Babcock wrote:
> > On Sun, 16 Aug 2009 18:49:49 -0400
> > Jason Martin  wrote:
> >
> >   
> >> On another note, how "Open Source friendly" is OAuth? I'm not sure
> >> if people who write open source software want to be giving out
> >> their Consumer Secret key in their source code
> >> 
> >
> > Reasoning from a faulty premise.
> >
> > When you know your code is going to be seen you either avoid doing
> > stupid things like hard coding credentials or you learn fast that
> > configuration data is not code.
> >
> > (Now where I did leave my virtual haddock?)
> >
> > Chris Babcock

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Paul Gallagher]

This is a good discussion - I've yet to find a canonical answer for how this
*should* be done for client-side/consumer apps.

If you are distributing a server application, then putting the application
registration instructions in a README is perhaps not such a big deal.
Desktop/mobile apps are another matter though.

It's also worth saying that even if you could find a secure way of
distributing a consumer key, you gotta ask if its even the right thing to be
doing. I think not. Definitely not. Once the code is "out there", I don't
want everyone authenticating with _my_ application registration and consumer
key (at this point, I have no way of knowing that the app hasn't been
modified in some way that I do not approve of. I risk one rogue instance
getting me blacklisted and in turn disabling every other instance. Great,
DoS by design).

Since the README approach is such a big no-no for client-side/consumer apps,
the question I'd be asking is: where is the API for performing an initial
application registration/bootstrap?

i.e. an example of the scenario I have in mind (considering a desktop app):
- user installs the app
- on first use, directs the user through online login to twitter and
automatic oauth client app request
- newly registered application credentials transparently returned to the
application (securely; somehow)
- application saves the (instance specific) application key and consumer
secret; uses these for standard oauth in subsequent sessions.

Does anything along these lines already exist? If so, I haven't stumbled
upon it yet.

Regards,
Paul
http://tardate.com


On Mon, Aug 17, 2009 at 9:01 PM, Joseph Cheek  wrote:

>
> This is interesting Chris, as I have had the same question.  How would
> you propose to distribute a usable FLOSS twitter app that uses Oauth to
> authenticate itself but doesn't include the app's consumer key and
> consumer secret?  fetch the key and secret at runtime from a secure
> server somewhere?  that could be trivially intercepted.
>
> Joseph Cheek
> @cheekdotcom
>
> Chris Babcock wrote:
> > On Sun, 16 Aug 2009 18:49:49 -0400
> > Jason Martin  wrote:
> >
> >
> >> On another note, how "Open Source friendly" is OAuth? I'm not sure
> >> if people who write open source software want to be giving out their
> >> Consumer Secret key in their source code
> >>
> >
> > Reasoning from a faulty premise.
> >
> > When you know your code is going to be seen you either avoid doing
> > stupid things like hard coding credentials or you learn fast that
> > configuration data is not code.
> >
> > (Now where I did leave my virtual haddock?)
> >
> > Chris Babcock
> >
> >
> >
> >
>

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[srikanth reddy]

@chris
You cannot ask every user to get new consumer token/secret.
There is no way you can protect a consumer secret.
@Joseph
<>
As far as i know this is the best way to hide the consumer secret. This will
not stop a determined user who try to intercept the keys but you have the
option of changing your key/secret values( for a consumer) periodically.
Other options are obfuscating/encrypting secrets at client side (again it
will not stop a determined user). But the key management is difficult here
as you have to download the app everytime(or whenever the risk of keys being
compromised is high)

Srikanth


On Mon, Aug 17, 2009 at 6:31 PM, Joseph Cheek  wrote:

>
> This is interesting Chris, as I have had the same question.  How would
> you propose to distribute a usable FLOSS twitter app that uses Oauth to
> authenticate itself but doesn't include the app's consumer key and
> consumer secret?  fetch the key and secret at runtime from a secure
> server somewhere?  that could be trivially intercepted.
>
> Joseph Cheek
> @cheekdotcom
>
> Chris Babcock wrote:
> > On Sun, 16 Aug 2009 18:49:49 -0400
> > Jason Martin  wrote:
> >
> >
> >> On another note, how "Open Source friendly" is OAuth? I'm not sure
> >> if people who write open source software want to be giving out their
> >> Consumer Secret key in their source code
> >>
> >
> > Reasoning from a faulty premise.
> >
> > When you know your code is going to be seen you either avoid doing
> > stupid things like hard coding credentials or you learn fast that
> > configuration data is not code.
> >
> > (Now where I did leave my virtual haddock?)
> >
> > Chris Babcock
> >
> >
> >
> >
>

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Joseph Cheek]

This is interesting Chris, as I have had the same question.  How would
you propose to distribute a usable FLOSS twitter app that uses Oauth to
authenticate itself but doesn't include the app's consumer key and
consumer secret?  fetch the key and secret at runtime from a secure
server somewhere?  that could be trivially intercepted.

Joseph Cheek
@cheekdotcom

Chris Babcock wrote:
> On Sun, 16 Aug 2009 18:49:49 -0400
> Jason Martin  wrote:
>
>   
>> On another note, how "Open Source friendly" is OAuth? I'm not sure
>> if people who write open source software want to be giving out their  
>> Consumer Secret key in their source code
>> 
>
> Reasoning from a faulty premise.
>
> When you know your code is going to be seen you either avoid doing
> stupid things like hard coding credentials or you learn fast that
> configuration data is not code.
>
> (Now where I did leave my virtual haddock?)
>
> Chris Babcock
>
>
>
>   

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Cameron Kaiser]

> > > When you know your code is going to be seen you either avoid doing
> > > stupid things like hard coding credentials or you learn fast that
> > > configuration data is not code.
> > 
> > Fair enough. So how do you do it? How do I distribute a desktop or
> > mobile device application - open source or closed - that uses my OAuth
> > credentials in such a way as to protect my credentials from being
> > discovered?
> > 
> > Seriously, how do you do that?
> 
> You don't distribute your credentials with the App. You include a
> README file that tells implementors how to get and install their own
> keys.

No barrier to entry there. ;-)

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- "I'd love to go out with you, but I'm rethreading my toothbrush bristles." -

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Joseph Cheek]

exactly.  and for those who think their closed-source oauth app hides
their app key and secret, have you ever run "strings" on your binary?

(for those keeping score, it's basic auth: 2, oauth: 0)

thanks!

Joseph Cheek
@cheekdotcom

JDG wrote:
> Which eliminates one of the biggest features of OAuth for a lot of
> app-writers -- the ability to put their app in the "source" parameter,
> thus eliminating the biggest piece of marketing they have.
>
> On Mon, Aug 17, 2009 at 08:59, Chris Babcock  > wrote:
>
>
>
> > On Aug 17, 6:27 am, Chris Babcock  > wrote:
> >
> > > When you know your code is going to be seen you either avoid doing
> > > stupid things like hard coding credentials or you learn fast that
> > > configuration data is not code.
> >
> > Fair enough. So how do you do it? How do I distribute a desktop or
> > mobile device application - open source or closed - that uses my
> OAuth
> > credentials in such a way as to protect my credentials from being
> > discovered?
> >
> > Seriously, how do you do that?
>
> You don't distribute your credentials with the App. You include a
> README file that tells implementors how to get and install their own
> keys.
>
> Chris Babcock
>
>
>
>
> -- 
> Internets. Serious business.

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[JDG]

Which eliminates one of the biggest features of OAuth for a lot of
app-writers -- the ability to put their app in the "source" parameter, thus
eliminating the biggest piece of marketing they have.

On Mon, Aug 17, 2009 at 08:59, Chris Babcock  wrote:

>
>
> > On Aug 17, 6:27 am, Chris Babcock  wrote:
> >
> > > When you know your code is going to be seen you either avoid doing
> > > stupid things like hard coding credentials or you learn fast that
> > > configuration data is not code.
> >
> > Fair enough. So how do you do it? How do I distribute a desktop or
> > mobile device application - open source or closed - that uses my OAuth
> > credentials in such a way as to protect my credentials from being
> > discovered?
> >
> > Seriously, how do you do that?
>
> You don't distribute your credentials with the App. You include a
> README file that tells implementors how to get and install their own
> keys.
>
> Chris Babcock
>



-- 
Internets. Serious business.

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Chris Babcock]

> On Aug 17, 6:27 am, Chris Babcock  wrote:
> 
> > When you know your code is going to be seen you either avoid doing
> > stupid things like hard coding credentials or you learn fast that
> > configuration data is not code.
> 
> Fair enough. So how do you do it? How do I distribute a desktop or
> mobile device application - open source or closed - that uses my OAuth
> credentials in such a way as to protect my credentials from being
> discovered?
> 
> Seriously, how do you do that?

You don't distribute your credentials with the App. You include a
README file that tells implementors how to get and install their own
keys.

Chris Babcock

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Bill Kocik]

On Aug 17, 6:27 am, Chris Babcock  wrote:

> When you know your code is going to be seen you either avoid doing
> stupid things like hard coding credentials or you learn fast that
> configuration data is not code.

Fair enough. So how do you do it? How do I distribute a desktop or
mobile device application - open source or closed - that uses my OAuth
credentials in such a way as to protect my credentials from being
discovered?

Seriously, how do you do that?

Re: Absurd Misunderstanding of Open Anything (Was: [twitter-dev] Re: Open Auth)

[Duane Roelands]

" I'll ask them for a username and password, and log them into OAuh
myself without them having to ever see a web browser."

Announcing that your application is doing an end-run around Twitter's
authentication protocols is a great way to get your app shut down.
Also, your application is likely to break if Twitter makes changes to
the OAuth page layout.

I have lots of issues with OAuth, but it's basic premise is sound:
OAuth allows people to use Twitter without giving away their Twitter
credentials.

On Aug 17, 6:27 am, Chris Babcock  wrote:
> On Sun, 16 Aug 2009 18:49:49 -0400
>
> Jason Martin  wrote:
> > On another note, how "Open Source friendly" is OAuth? I'm not sure
> > if people who write open source software want to be giving out their  
> > Consumer Secret key in their source code
>
> Reasoning from a faulty premise.
>
> When you know your code is going to be seen you either avoid doing
> stupid things like hard coding credentials or you learn fast that
> configuration data is not code.
>
> (Now where I did leave my virtual haddock?)
>
> Chris Babcock