On Sat, 12 Jun 2010 13:25:44 -0700
Zac Bowling <zbowl...@gmail.com> wrote:

> On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> > Application authors are being asked to devote substantial resources
> > to the OAuth conversion, but OAuth provides no security for
> > application authors!
> 
> It does from a web app perspective which is the primary design goal
> of OAuth since there would be no distribution of your secret in that
> scenario.

Precisely. OAuth is designed for a 3-party security deal: Twitter
running on some host, the App running on another host, and the User
running on a third.

OAuth is pretty useless for a 2-party situation, as is present in a
desktop/mobile app on the users device. This isn't all that surprising,
since it is designed for something different.


> ... shipped are at risk then. Your only recourse is to rev your secret
> and force all your users to upgrade their apps to get new keys. 

Another recourse might be to design a security approach for the
app-on-user-device scenario, rather than trying to shoehorn a 3-party
scheme into this.

> .. this isn't that bad since twitter isn't hosting credit card
> data or anything of major risk and you basically devolve into the
> same issue we had with app identify we had with basic auth and
> passing clear text source ids (except that maybe now all your apps
> are crippled).

Right. As long as the app doesn't do any side business with a third
party. If it does, then it should not use twitter's authentication for
that purpose.
 
> I've been pondering how you could solve this from my experience with
> solving these issues with SSL/TLS. One idea is having a sort of
> delegation chain where I could generate a new delegated secret for
> each copy of my app I distribute rather then using my same static
> secret directly in all my apps and then the client could pass the
> authentication chain up when it goes to Twitter to get an access
> token. 

The question is also - why do you care which copy of your app it is?
People using your app will post silly things, engage in slander of
other people, commit crimes, plot revolutions. 

Are you responsible for these things? 

Is Twitter responsible for broadcasting the content? 

While we're at it, let's go after the phone manucacturer, the network
bandwidth provider.

> ...
> Right now though, one solution if you are ultra paranoid if you are
> going to distribute software, is to proxy the calls from your own
> software through your own web service (which would render the ease of
> use you get from xAuth moot but you are sacrificing usability for
> security). 

You mean something like Microsoft authorization codes. 

Or make them download a UUID with the code, and send that code to
twitter for each individual downloaded copy. Of course once the
download count goes into the millions, twitter will love to store all
those IDs. And of course every application developer has a website that
handles all the downloads, none of them use google code, sourceforge,
github, ... oh wait.

Oh well, why bother.

-- 
Bernd Stramm
<bernd.str...@gmail.com>

Reply via email to