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
