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