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
