"secure" key -> desktop applications?

[Tom van der Woerdt]

Hi all,

I'm wondering why there's a "secret" key if you need to include it with
desktop applications... Of course, there's the client secret key which
needs to remain secret, but why is there a secret key for applications
if it doesn't remain secret?

Is it the combination of the 4 keys that always needs to remain private?
The consumer key, consumer secret, and client token are, of course, safe
to present to people (but still unwise, so I won't).

It simply doesn't feel right to be including "secret" keys in an
application - everyone could see them and they wouldn't be secret, would
they?

As far as I have seen so far, the only thing you can do with a consumer
secret key, is signing the requests and requesting tokens (or, in my
case, use xAuth). Is there any reason why I shouldn't include the secret
key in my application? Anything that can damage my twitter account
and/or the application?

Tom

[Taylor Singletary]

Hi Tom,

I'm happy you're fully considering the implications here. With desktop applications, it's a matter of "best effort" security with your consumer secret and access token secrets. We recommend making it difficult to obtain the keys from a packaged application, while acknowledging that a determined hacker would be able to obtain them. That's where monitoring and damage control comes in -- we give all app developers the ability to reset/regenerate their consumer key and secret at any time, which is an effective "kill switch" for the former secrets. As time goes on, we hope to provide more tools that will help application developers detect application abuse. 

xAuth adds further complication if the keys are compromised, but should any rogue exchange logins for access tokens, regenerating your consumer key and secret will again cut them off from using those access tokens without the most recent key combination. 

We do our best to monitor for abuse and proactively stub out issues when they arise. There are some alternatives you can explore that would still protect your Twitter credentials, such as using the API through a homebrew proxy that actually holds the keys, or using a home-brew OAuth scheme between your application and a server to retrieve the keys securely. I'm not actually recommending these avenues, but they are options.

The potential damage should your key get hijacked won't really effect your user account (unless you provide your access tokens in the application -- not a good idea), and the most damage likely to your application would be a temporary suspension and potential fallout from any actions taken by the hacker on behalf of your application (issuing Tweets/Spam/etc.)

Taylor

[Tom]

Hi Taylor,

Thanks for your reply.

What I am currently considering is a connection to my server to
exchange
keys - which you mentioned. The xAuth part would be done from my
server,
the oAuth on the client.

I wrote it like this from the start - exchanging keys with my server -
because I didn't read the documentation entirely. I was under the
impression that only a normal secret key was needed to sign
client-requests, while the consumer secret was only used for logging
in
people. When I wanted to send my first tweet from my app, I noticed
that
it didn't work and after a few hours of debugging it seemed that I
needed both secret keys. Implemented that, and it worked.

Yet still it makes no sense. If a consumer key is needed for allowing
an
user to use your application and get a client key, why would you still
need the consumer key? For all other requests those 2 keys simply go
together, so why not make a normal client twice as long?

Sure - I can implement it the way the oAuth is used, but it seems
wrong.

Tom



On Jun 23, 5:18 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:

> On Wed, Jun 23, 2010 at 2:12 AM, Tom van der Woerdt <allerleiga...@gmail.com

[Jef Poskanzer]

You're right in theory that requests after the initial authentication
step should not really need the app's credentials, a single
authentication token & secret ought to suffice and the service
(twitter) should remember which app each token came from. But shrug,
that's just not the way OAuth works. It's not twitter's fault, they
are just following the spec. I can't even say it's particularly
unreasoinable - flickr's similar three-party authentication protocol
is much simpler than OAuth but it still uses the app key on every
request.

As for embedding the app secret in desktop and mobile executables and
trusting that it will be just too difficult for miscreants to extract,
I say don't do it. The OAuth RFC says so too. Keeping the secret in
a server-side proxy is probably the best solution.

[Tom]

Sure, that's an option, but not one which I would likely take, for
multiple reasons, including rate limiting which I would like to apply
to my client (my server is whitelisted so all accounts would suddenly
get 20000 -> that's a bad idea).

I was wondering how the "big" clients do this, like TweetDeck, Twitter
for iPhone, Gwibber, DestroyTwitter, TwitterBerry, etc. Is their key
storage so secure that they have never had a key leak, or do they
implement oAuth differently? I doubt that all of their requests go via
a server...

Also, I know that this may sound a bit stupid, but I'd like to propose
a change in oAuth (1.1?) so that it's no longer needed to supply both
keys. Where can I do this?

Tom