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:
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
On Wed, Jun 23, 2010 at 2:12 AM, Tom van der Woerdt allerleiga...@gmail.com
wrote:
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
