OK ... let me make *sure* I understand this. Is this the "best
practice?":

1. I write a desktop application. Whether it's closed or open source
is irrelevant. I advertise this application for sale, saying, "It runs
on Windows, Macintosh and Linux desktops (KDE, Gnome, XFCE, let's
say), it does all these wonderful things, *and* it's oAuth-secure!"

2. I *sell* Bob a copy of my application. It contains code but *no*
oAuth tokens of any kind.

3. Bob installs the application. Bob starts up the application.

4. The application starts up the browser and points it to
http://twitter.com/apps/new, and directs Bob to do the following:
    4.a. Log in to Twitter.
    4.b. Fill in the form. I tried this with a dummy application, and
the Application Name must be *unique*. So what does Bob put in this
field? "Bob's copy of Ed's wonderful application?"
    4.c. Now Bob has a consumer key and consumer secret, unique to
*his* copy of the application, *not* generic to the application.

5. The application instructs him to enter the freshly-minted consumer
key and secret via copy and paste into a dialog box, checks them for
validity against the Twitter oAuth servers, and then stores them
someplace that an attacker can't find them. This is, of course,
platform dependent - the application needs special code for Windows,
Mac, and at least two Linux desktops. See 
http://apiwiki.twitter.com/Security-Best-Practices
for the application's responsibilities in this area.

6. OK, now Bob has "registered the application with Twitter". He
actually wants to use it now. The application starts up, picks up the
stored consumer key and secret, starts up the browser again, and goes
to the PIN-generation site. If Bob hasn't logged in to Twitter yet,
that site will ask him to do so. Bob gets his PIN and copies it into a
dialog box. The application does its thing, and Bob tweets about how
wonderful it is that he can do all this stuff with Ed's wonderful
application. I sell 3,000 copies of it, hire a support engineer, and
make the front page of Mashable! ;-) But there's two ways I can go
with this:
   6.a. Grant Bob indefinite permission by getting the PIN once and
storing the resulting tokens on his machine, again "someplace that an
attacker can't find them."
   6.b. Require Bob to get a new PIN each time he uses the
application.

What's the "best practice" here? Personally, I'm leaning towards a new
PIN each time as long as it isn't an impact to Twitter servers,
because it exposes one less place for an attack.

--
M. Edward (Ed) Borasky
http://borasky-research.net/smart-at-znmeb

"A mathematician is a device for turning coffee into theorems." ~ Paul
Erdős

Reply via email to