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

Reply via email to