That's what I would say as well, but for applications with xAuth access they can be used to test whether a username/password combination is valid (from a hacked database, for example). If your application doesn't have xAuth access, I don't see a reason either. However, it's the rules.

To be honest, I'd say that "hiding" them as plaintext is fine. Twitter does it the same way in their own applications and they can't expect you to have higher standards than they do.

Tom


On 6/22/11 9:21 AM, Brian Remmington wrote:
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<i...@tvdw.eu>  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

Reply via email to