I do not feel you've made a mountain out of a mole hill here. This topic has been on my mind since I first encountered oAuth. I haven't seen any open source apps use oAuth yet.
We have an open source application called Application X. The potential risk is that Application X becomes widely adopted, thus having a higher risk of being impersonated. For instance, malware could then use the tokens from Application X to obtain authorization from Twitter. This would require the user to authorize the impersonator via Twitter since it is likely a new session token would be generated. Potentially the user would likely trust this impersonator and not think twice about authorizing it because they will see "Application X" on Twitter.com. Once they click allow the impersonator has control of their account. Even if the malware doesn't spread quickly it would possibly be harder to track since it would appear to be communications from Application X. I am not one to cry fowl over an issue like this, just merely throwing this out here as an idea. Anyone else have any ideas how to secure open source oAuth apps? On Jul 1, 6:24 am, DWRoelands <duane.roela...@gmail.com> wrote: > It seems as though revealing the Consumer Key and Consumer Key Secret > of my application would be a pretty serious security risk. Anyone > could write an application that impersonates mine, but they still > would need an authorized user's Token and Token Secret in order to > commit mischief. > > What sort of nastiness could one do in the Twitter environment with > someone else's Consumer Key and Consumer Key Secret? > > Am I making a mountain out of a molehill here? If this is not a big > deal, I'd like to hear so so I can continue working on my project as > an open source endeavor. If this is a serious security issue, then I > have to close the source for my project (and obfuscate the source). > > --Duane > > On Jun 30, 9:29 pm, Alex Payne <a...@twitter.com> wrote: > > > > > That's a solution that better fits open source Twitter web services. For an > > open source desktop client like Spaz it certainly doesn't work. > > > On Tue, Jun 30, 2009 at 16:37, DWRoelands <duane.roela...@gmail.com> wrote: > > > > Wait, the solution is that every -user- of an open-source Twitter > > > client would have to register for their own set of -consumer- keys? > > > > That's not what you meant, is it? > > > > On Jun 30, 4:39 pm, Alex Payne <a...@twitter.com> wrote: > > > > The simplest solution is that every deployment of the tool will have to > > > > register for their own OAuth credentials. This isn't ideal. I'd inquire > > > over > > > > athttp://groups.google.com/group/oauth > > > > > On Tue, Jun 30, 2009 at 06:04, DWRoelands <duane.roela...@gmail.com> > > > wrote: > > > > > > This is really an excellent question. > > > > > > If we're developing an open-source Twitter client, how are we supposed > > > > > to handle the consumer_key and consumer_key_secret? > > > > > > On Jun 29, 7:58 pm, Support <supp...@yourhead.com> wrote: > > > > > > 2. Obfuscation of the application's registered "key" and "secret." > > > > > > Are there any best practices? What about an open source project? > > > > > -- > > > > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x > > > -- > > Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x
