Thanks for your reply, Tom. Something I'm not certain of is why it
matters if people know your app's key and secret. What's the worst
that can happen? They would still need to carry out operations as a
valid Twitter user. Presumably if someone were to use Tweetdeck to
spam, it would be that user that would be blocked, not all Tweetdeck
users in the world?
On 21 June 2011 17:07, Tom van der Woerdt wrote:
> Twitter's own handling of keys varies. For example: Twitter for iOS has the
> keys plaintext in the code. The iOS5 library actually doesn't store them as
> plaintext, but encrypts the consumer key the same way as the consumer
> secret, which still means it's easy because once you have the consumer key
> (packet sniffing?) you'll know how to get the secret. (Believe me, it's
> almost easier than that.)
>
> Those are two examples of how NOT to do it.
>
> I can give you these tips:
> * Don't encode your consumer key or don't use the same algorithm as the
> secret. The consumer key is supposed to be non-secret information as it is
> also transmitted on the request. If you can get the decoded version of the
> consumer key and the encoded version of the consumer key, it's often easy to
> reverse-engineer the algorithm.
> * Write your encryption in a "safe" language. For example, Objective-C is
> *very* easy to use with a debugger. C++ however, is not. Write your hashing
> code in C++ (hashing code: getting the secret all the way up to doing the
> HMAC hash). Also try to avoid using system libraries for the HMAC:
> preferably implement it yourself. This will make it harder as the "attacker"
> won't know what to target.
>
> Of course, these won't really work with opensource applications, as everyone
> can get the keys. If you distribute your application under a GPL license,
> there isn't much you can do, as you're forced to share the code (which
> include the keys).
>
> There are currently two options for OS projects I can think of :
> * Route all your requests via an application on your server (the TweetDeck
> way: just redirect api.tweetdeck.com to api.twitter.com but sign the
> requests with your key. However: this *will* cause issues with POST
> requests, so you'll have to handle those on your sever which may cause some
> heavy load)
> * Have your users register an application on dev.twitter.com/apps.
>
> Tom
>
>
> On 6/21/11 5:08 PM, Brian Remmington wrote:
>>
>> What techniques are people using to keep their Twitter app's consumer
>> key and consumer secret, um, secret? What lengths are you going to to
>> make sure nasty people can't get at this information? I have a
>> particular problem in that I want my app to be open source - does
>> anyone have any experience of building open source apps that interact
>> with Twitter (or other services that use OAuth)? Thoughts?
>> Suggestions?
>>
>>
>> Brian
>>
>
> --
> Twitter developer documentation and resources: https://dev.twitter.com/doc
> API updates via Twitter: https://twitter.com/twitterapi
> Issues/Enhancements Tracker:
> https://code.google.com/p/twitter-api/issues/list
> Change your membership to this group:
> https://groups.google.com/forum/#!forum/twitter-development-talk
>
--
Twitter developer documentation and resources: https://dev.twitter.com/doc
API updates via Twitter: https://twitter.com/twitterapi
Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list
Change your membership to this group:
https://groups.google.com/forum/#!forum/twitter-development-talk
