I am writing a opensource desktop client and has implemented OAuth for
it. However, I don't know is it suitable to put my key and secret in
the source? Are there any risks if i do that?
Thx :)
So I doubt that is it a good way to use OAuth in Desktop Client.
On Jan 30, 1:35 am, Raffi Krikorian <ra...@twitter.com> wrote:
> the leak of a consumer secret will not result in the compromising of user
> accounts (the consumer secret is needed to get user secrets, but to get user
> secrets require the user's intervention).
>
> however - do not put the consumer key and secret in the source of your code
> and distribute it. instead, make it possible for your source to read the
> consumer key and secret from a configuration, and distribute, with your
> source code, a sample configuration file or a README that details how to
> create one.
>
> hope that helps.
>
The OAuth secret is simply impossible to use securely with open
source, end-user-oriented applications. My only option with Spaz, when
Twitter decides to take away basic auth, is to pray someone doesn't
decide to steal my "secret" hash.
Compiling does make getting the key more difficult, but assuming that
desktop apps are compiled isn't a good idea -- Spaz isn't, for
example. I could obscure the code for the end user, I suppose, but
doing so seems contrary to open source philosophy, and probably just
presents a challenge.
OAuth as-is just wasn't designed for desktop apps, period. Square peg,
round hole. If Twitter is insisting on it, I'd rather this was
portrayed as a trade-off for increased user security, than a solvable
problem -- I don't think it is.
On Jan 30, 2:22 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> what i would do is just make it clear to people who are using your open
> source client that they need to register their downloaded application with
> Twitter -- send them tohttp://twitter.com/apps/new, instruct them to fill
Josh
+1
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- "I'd love to go out with you, but I'm in perpetual denial." ----------------
Sent using BlackBerry® from Orange
what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple "wizard" that they can cut and paste the consumer token and secret into.
What I want to know is that: in my distributed version, should I
include the key/secret in the config file(or hardcode in source, it
doesn't matter)?
So, in simple language: Twitter's policy is that every user of every open source client register as a new twitter application?
Or, have I misinterpreted something? And if so, could you explain further what mean?
-- mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see <http://www.elehack.net/resources/gpg>.
This still requires the developer maintain a server to perform the
consumer pair generation, but it does keep the "master" pair secure
and each application gets its own pair. But applications that are
willing to make this trade off can keep the UX good, control what
application instances can authorize on the application's behalf, and
the "master" pair is never shared. You can always still distribute the
"master" pair with each application if these security gains are not
that important to you. Or you can require your users to generate their
own consumer pair if UX is not much of an issue (example: distributed
server applications) where an advance users is at the wheel and won't
have issues figuring this out.
Josh
I like those ideas. They match up maintaining a consistent application
identity with better key security. The first one seems more workable.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- I couldn't care less about apathy. -----------------------------------------
Josh
If you include the key, sooner or later it will be found. Just ask Jon
Lech Johansen.
It may not be worth it for apps with small user bases, but that's not much
security.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- In Computer Science, we stand on each other's feet. -- Brian Reid ----------
Josh
I wonder if Twitter could provide developers with an URL for
dynamically generating additional consumer tokens for their
applications. When the user installs a new application it will contact
the developer's server to download its own consumer key/secret. The
developer's server will use its "master" consumer key/secret to post
to the Twitter URL to fetch a new consumer key/secret. The consumer
pair will then be sent to the application via a secure channel
(HTTPS?) to prevent man in the middle attacks. The application will
then use this new consumer pair to perform all signing of requests.
Another option is to package the dynamically generated consumer pair
in the application download package. Each new download will have its
own unique consumer pair ready for use once the user has downloaded
the application.
Twitter will have to do something to combat application impersonation.
Let's say your app is MyAppName and your URL is http://www.myappname.com.
Currently, anyone can register an app MyApppName or MyAppnName and
give http://www.myappname.com as the URL for the app, with zero
verification. They can do all kinds of naughty things, and your app is
going to take the blame for it in most users' minds.
On Jan 31, 3:19 pm, Abraham Williams <4bra...@gmail.com> wrote:
> I would like to point out the official Flickr Uploadr application that is
> OAuth and open source. If you download it as a user [1] it includes their
> official API keys but if you download it as a developer [2] you implement
> your own API keys.
>
> Ironically all of these massive threads talking about impersonating
> applications is probably just making more crackers aware that they can do
> this. :-/
>
> Abraham
>
> [1]http://www.flickr.com/tools/uploadr/
> [2]http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76
>
>
>
> On Sun, Jan 31, 2010 at 10:06, Josh Roesslein <jroessl...@gmail.com> wrote:
> > That's not all that secure, eventually it will be loaded into memory
> > and can be found by any hacker with some patience. As soon as you
> > distribute any sort of data it is no longer private. You're average
> > Joe might not be able to find it, but any skilled hacker will. And
> > after all the average Joe does not care anyways about OAuth tokens
> > ("what's oauth?"), but hackers do. So you're kind of blocking the
> > wrong person, it's the hacker you want to stop.
>
> > Josh
>
> > On Sun, Jan 31, 2010 at 2:28 AM, <scott.a.herb...@googlemail.com> wrote:
> > > I 100% agree.
>
> > > But another idea just struck me, why not put the OAuth part of your app
> > in a DLL (at lest the authentication and communication with twitter part)
> > and hard code it their.
>
> > > You lose some of the open source nature of the app but it will be secure.
>
> > > Sent using BlackBerry® from Orange
>
> > > -----Original Message-----
> > > From: Cameron Kaiser <spec...@floodgap.com>
> > > Date: Sat, 30 Jan 2010 23:02:18
> > > To: <twitter-deve...@googlegroups.com>
> > > Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
> > oauth
> > > in Desktop Client
>
> > >> OAuth as-is just wasn't designed for desktop apps, period. Square peg,
> > >> round hole. If Twitter is insisting on it, I'd rather this was
> > >> portrayed as a trade-off for increased user security, than a solvable
> > >> problem -- I don't think it is.
>
> > > +1
>
> > > --
> > > ------------------------------------ personal:
> >http://www.cameronkaiser.com/--
> > > Cameron Kaiser * Floodgap Systems *www.floodgap.com*
How is it better or more secure to have crackers misappropriated your sub key to mimic your application instead of your primary key? They are still pretending to be your application and users won't know any different. If each sub key had its own listing on https://twitter.com/account/connections then there would be some differentiation but then if users install an application five times it would be listed five times.Abraham
Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/
Pointing out what Flickr does is fine, but they're also in more of a
position to address possible abuses of their own API key as both the
consumer and the provider. App devs will have to hope that the API
support team responds quickly to these issues – and without and SLA or
support agreement in most cases, Twitter is under no obligation to
care. I hope it's *not* like that, but I think we've all seen cases
where feedback and response time wasn't what we'd like.
I agree that much of this seems like beating a dead horse, but I'd
also like to see more official response about it, even if it's just
"hey, we know, and this is just the tradeoff we need to make."
Otherwise, I think we're providing feedback as requested on the API in
general, and authentication in particular.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funk...@gmail.com
On Jan 31, 2:19 pm, Abraham Williams <4bra...@gmail.com> wrote:
> I would like to point out the official Flickr Uploadr application that is
> OAuth and open source. If you download it as a user [1] it includes their
> official API keys but if you download it as a developer [2] you implement
> your own API keys.
>
> Ironically all of these massive threads talking about impersonating
> applications is probably just making more crackers aware that they can do
> this. :-/
>
> Abraham
>
> [1]http://www.flickr.com/tools/uploadr/
> [2]http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76
>
>
>
>
>
> On Sun, Jan 31, 2010 at 10:06, Josh Roesslein <jroessl...@gmail.com> wrote:
> > That's not all that secure, eventually it will be loaded into memory
> > and can be found by any hacker with some patience. As soon as you
> > distribute any sort of data it is no longer private. You're average
> > Joe might not be able to find it, but any skilled hacker will. And
> > after all the average Joe does not care anyways about OAuth tokens
> > ("what's oauth?"), but hackers do. So you're kind of blocking the
> > wrong person, it's the hacker you want to stop.
>
> > Josh
>
> > On Sun, Jan 31, 2010 at 2:28 AM, <scott.a.herb...@googlemail.com> wrote:
> > > I 100% agree.
>
> > > But another idea just struck me, why not put the OAuth part of your app
> > in a DLL (at lest the authentication and communication with twitter part)
> > and hard code it their.
>
> > > You lose some of the open source nature of the app but it will be secure.
>
> > > Sent using BlackBerry® from Orange
>
> > > -----Original Message-----
> > > From: Cameron Kaiser <spec...@floodgap.com>
> > > Date: Sat, 30 Jan 2010 23:02:18
> > > To: <twitter-deve...@googlegroups.com>
> > > Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
> > oauth
> > > in Desktop Client
>
> > >> OAuth as-is just wasn't designed for desktop apps, period. Square peg,
> > >> round hole. If Twitter is insisting on it, I'd rather this was
> > >> portrayed as a trade-off for increased user security, than a solvable
> > >> problem -- I don't think it is.
>
> > > +1
>
> > > --
> > > ------------------------------------ personal:
> >http://www.cameronkaiser.com/--
> > > Cameron Kaiser * Floodgap Systems *www.floodgap.com*
I'm not convinced that distributing *any* oAuth capability to end
users, even in binary form - even in a form where said binary
interfaces in secure ways with the underlying desktop / mobile ways to
persist the consumer key and secret - is the "way to go". I personally
think the "way to go" is to deploy applications as servers with the
thinnest possible client imaginable. If ChromeOS netbooks actually
existed today, that's what I'd be building - servers that interacted
with Twitter on behalf of users with ChromeOS netbooks.
Given what I know now about oAuth, I'm not planning on releasing any
oAuth desktop applications. I never *was* planning mobile ones - the
kind of processing I have in mind flat out can't be done on a mobile,
so I'd have to have a server anyway to deploy to mobile users.
> I'd say its a pretty reasonable bet that one of the major desktop clients
> will be compromised within a year or so of implementing OAuth -- and will
> probably result in a lot of user frustration. It seems like their will be
> ample motivation and little to prevent them.
> Only time will tell, you're free to come and laugh at me if it doesn't
> happen. Bookmark this email, we'll check back in 18 months. ;-)
> Isaiah
Well ... the motivation is there now, with or without oAuth. And oAuth
doesn't make it *easier* to compromise a desktop application. As far
as desktop "user frustration" is concerned, though, there are so many
other sources of desktop user frustration already - botnets, weekly
virus scans that take hours, browser vulnerabilities, 15-30 minute
waits before the machine is "open for business", and, of course, the
hundreds of dollars one pays per year for just a license to use the
desktop software - that I think a compromised Twitter desktop platform
isn't going to get much attention unless it does something really
nasty, like a DDOS against Twitter.
--
M. Edward (Ed) Borasky
http://borasky-research.net
"I've always regarded nature as the clothing of God." ~Alan Hovhaness
I think Twitter's engineering team does understand the issues. But I
think the primary responsibility lies with us developers, and I for
one don't see the point in investing effort building desktop Twitter
applications, given
a. They're tough to scale down to mobile platforms, and mobile usage
seems to be where the growth and action are in social media, and
b. oAuth or not, desktop applications are difficult to secure.
c. The Streaming API isn't designed to play well with desktops /
laptops / mobiles.
> I agree that much of this seems like beating a dead horse, but I'd
> also like to see more official response about it, even if it's just
> "hey, we know, and this is just the tradeoff we need to make."
> Otherwise, I think we're providing feedback as requested on the API in
> general, and authentication in particular.
The environment in which Twitter and the Twitter development community
operate is changing rapidly. The *desktop* oAuth tradeoffs may have
made sense a year ago. before the huge growth spurt in awareness and
usage of Twitter in 2009. As I've noted, I think the *server* oAuth
tradeoffs still make sense. I think we need to take the advice of
Wayne Gretzky and "skate to where the puck is going to be."
I should also note that I have never used a "desktop Twitter client".
I installed one once on my Linux workstation, and got frustrated by
the Adobe AIR platform issues. The client wasn't giving me any
functionality I couldn't get from a free server like HootSuite or even
from Firefox, and there wasn't anything else I wanted that used AIR.
So I'm not losing anything if "desktop oAuth" doesn't get "enhanced".
So don't develop one. But, speaking as a dev who eats his own dog food, I
prefer to have a console open running TTYtter than mashing refresh all the
time in Camino. Desktop apps are a useful part of the ecosystem, and I
wouldn't be participating in Twitter anywhere near as much as a user if I
had a much higher barrier to do so or had to trust a third-party service and
add another layer on to do so on my behalf. I assume @funkatron's users
have the same opinion.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- LET'S GO FORWARD ... INTO THE PAST! ----------------------------------------
Yes, I write my own desktop apps too, but I don't distribute them. I
never saw the need to use a desktop client when the browser worked
just fine. Then again, I don't own a Mac and don't use Windows very
often. Maybe a desktop client on a Windows or Mac makes more sense
than it does on Linux. Assuming, of course, that a Linux desktop
itself makes any sense - there aren't a lot of folks who agree with me
on my choice of desktop. ;-)
c. The Streaming API isn't designed to play well with desktops /
laptops / mobiles.
The environment in which Twitter and the Twitter development communityoperate is changing rapidly. The *desktop* oAuth tradeoffs may have
made sense a year ago. before the huge growth spurt in awareness and
usage of Twitter in 2009. As I've noted, I think the *server* oAuth
tradeoffs still make sense. I think we need to take the advice of
Wayne Gretzky and "skate to where the puck is going to be."
As I understand it, the Streaming API uses only Basic Authentication
*without* SSL. That frightens me. It means anyone who can sniff
traffic at the hosting site I use can hijack the account I use for
Streaming API access.
Now that the Streaming API is no longer beta, will Twitter be providing
some more secure mechanism for authenticating?
-Marc
My choice of words was wrong. I don't remember the exact language - I
can find it if necessary - but when the Streaming API was released to
production status, John Kalucki said that desktop developers should
hold off on production use of Streaming but that it was OK to test
with it.
But Streaming is a steady, hopefully uninterrupted flow of tweets.
Those have to be buffered / persisted for at least some length of time
for them to be useful beyond just "displaying breaking news". Mobiles
don't have the space and have limited memory and processing
capabilities. And if they're going to be always on and always
collecting / processing data, they have to be plugged in.
I can see a case for building a desktop app with Streaming, provided
you have a backup mechanism for data collection in case your desktop
needs to be rebooted. But laptops are essentially the same deal as
mobiles - they aren't always plugged in to a power source.
>> The environment in which Twitter and the Twitter development community
>> operate is changing rapidly. The *desktop* oAuth tradeoffs may have
>> made sense a year ago. before the huge growth spurt in awareness and
>> usage of Twitter in 2009. As I've noted, I think the *server* oAuth
>> tradeoffs still make sense. I think we need to take the advice of
>> Wayne Gretzky and "skate to where the puck is going to be."
>
> i just want to really emphasize that we all do energetically read these
> email threads and try to learn as much as we can from them. this thread, so
> far, has been great.
I've said this before, but maybe not here. As a developer I've worked
with a number of companies over the years, and I can't think of any
that was easier to work with than Twitter. Part of it is the
simplicity of the API - have a look at Google's or Facebook's some
time. ;-) But a bigger part is that you do understand what our
challenges are.
It's not just oAuth and it's not just Twitter - mobile and desktop
security is a big challenge. Microsoft has been unable to stop the
spread of botnets on Windows, and only the relative rarity of Mac and
Linux desktops has prevented them from becoming botnet targets as
well. Google's idea of a locked-down netbook that can't be compromised
without a screwdriver and a soldering iron is looking very good to me
right now. ;-)