Amen and thank you Matt.
On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanford<m...@twitter.com> wrote: > > > On Jul 1, 2009, at 5:10 AM, Philip Plante wrote: > >> >> 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. > > One thing the above description leaves out is that not only would the > user have to approve the application, but that since it is a desktop > application they would have to type the PIN number back into the > MalewareApp. Perhaps the PIN-flow for desktop applications was not taken > into account, or maybe the wording on the PIN pages should be stronger, but > that's pretty much why we added the PIN flow. > In my mind server-side applications should not publish a consumer > key/secret. There is an assumption here that anyone savvy enough to install > your wildly successful open source server-side application can register a > key/secret … and that they probably want callbacks going to the correct > site. This is not unlike the current Twitter/OAuth libraries, which all > require you to get your own key. > > >> >> 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 > >
