A technical solution I see working is a modified PIN flow where instead of a 6 digit PIN the user gets a 20 character token that acts as consumer token. No harder then using PIN flow but each desktop install would have a unique consumer sub token that could still be tied into the global consumer token.
Abraham On Wed, Jul 1, 2009 at 10:11, Andrew Badera<[email protected]> wrote: > > Amen and thank you Matt. > > > On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanford<[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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 <[email protected]> >>>>>> >>>>>> 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 <[email protected]> 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 >> >> > -- Abraham Williams | Community Evangelist | http://web608.org Hacker | http://abrah.am | http://twitter.com/abraham Project | http://fireeagle.labs.poseurtech.com This email is: [ ] blogable [x] ask first [ ] private.
