This isn't a zero-day vuln that hasn't been reported to the vendor, so I think any suggestion that keeping it on the DL is not helpful. This is a known issue with application of the OAuth spec. Educating the developers who read this list, and maybe helping Twitter's engineering team understand the problems better, should be top priority.
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:funkat...@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-development-talk@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* > > ckai...@floodgap.com > > > -- "I'd love to go out with you, but I'm in perpetual denial." > > ---------------- > > -- > Abraham Williams | Community Advocate |http://abrah.am > Project | Out Loud |http://outloud.labs.poseurtech.com > This email is: [ ] shareable [x] ask first [ ] private. > Sent from Seattle, WA, United States
