[twitter-dev] Re: Security Best Practices

2009-07-05 Thread Andrew Badera

I wasn't thinking about downstream requests where you still need both
tokens, just token requests ... yeah, that's rough.




On Sat, Jul 4, 2009 at 10:38 PM, Dossy Shiobarado...@panoptic.com wrote:

 On 7/4/09 5:30 AM, Andrew Badera wrote:

 I haven't done much real desktop OAuth, mostly web ... but can't you
 simply proxy the request through your own server, and keep the secret
 on your server, serving client requests centrally?

 Yes, yes you can - then you get to enjoy the Twitter rate limit issue and
 having to scale to accomodate concurrent sessions.

 The beauty of desktop applications is the decentralized nature, using
 resources close to the user (as opposed to further away on a server).
  This means scaling per user is built in as the user brings their own
 resources.

 OAuth's implicit requirement of funneling everything through a server in
 order to protect a secret is a defect in the design of OAuth, one that I've
 raised on the OAuth mailing lists to which I received the response of well,
 that's not a problem OAuth is trying to solve.  In other words: EPIC FAIL.

 --
 Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
 Panoptic Computer Network   | http://panoptic.com/
  He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on. (p. 70)



[twitter-dev] Re: Security Best Practices

2009-07-04 Thread Dossy Shiobara


Hint: This isn't a dilemma for only open source developers.  It's a real 
and serious problem for any application whose code (source or object) is 
accessible to anyone other than the application developer,

i.e., any application that the user installs.

It should take all of, what, a day, to create a list of the top 10 
desktop Twitter apps and their corresponding consumer key and secret.


It's all fun and games until someone discloses a secret.  Then, it's 
just fun ...



On 7/1/09 9:32 AM, Andrew Badera wrote:

The secret should not reside in code. The secret should reside in a
config file, or maybe even a machine datastore. Abstract it out, no
one ever needs to see anything secret in your code.

Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera
- This email is: [ ] bloggable [x] ask first [ ] private



On Wed, Jul 1, 2009 at 9:25 AM, DWRoelandsduane.roela...@gmail.com  wrote:

If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/
core/1.0#anchor4) states it pretty plainly:

Service Providers SHOULD NOT rely on the Consumer Secret as a method
to verify the Consumer identity, unless the Consumer Secret is known
to be inaccessible to anyone other than the Consumer and the Service
Provider.

This is exactly what Twitter has done with the Consumer Secret; they
rely on it to verify the Consumer identity.

This is a thorny dilemma for open source developers.  There's no way
to share the source code without compromising your application's
security, because you've got to include the Consumer Key Secret in the
source.  You can obfuscate and encrypt, but a malicious actor with
access to the source code can simply step through the code until the
Consumer Secret is exposed in plain text.

In any event, what's done is done, and Twitter certainly isn't going
to abandon OAuth at this point.  But opening the source of my Twitter
client seems to be out of the question if I want to use OAuth.


On Jul 1, 8:10 am, Philip Plantepplante@gmail.com  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.



--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


[twitter-dev] Re: Security Best Practices

2009-07-04 Thread Andrew Badera

I haven't done much real desktop OAuth, mostly web ... but can't you
simply proxy the request through your own server, and keep the secret
on your server, serving client requests centrally?

Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera
- This email is: [ ] bloggable [x] ask first [ ] private



On Sat, Jul 4, 2009 at 4:56 AM, Dossy Shiobarado...@panoptic.com wrote:

 Hint: This isn't a dilemma for only open source developers.  It's a real and
 serious problem for any application whose code (source or object) is
 accessible to anyone other than the application developer,
 i.e., any application that the user installs.

 It should take all of, what, a day, to create a list of the top 10 desktop
 Twitter apps and their corresponding consumer key and secret.

 It's all fun and games until someone discloses a secret.  Then, it's just
 fun ...


 On 7/1/09 9:32 AM, Andrew Badera wrote:

 The secret should not reside in code. The secret should reside in a
 config file, or maybe even a machine datastore. Abstract it out, no
 one ever needs to see anything secret in your code.

 Thanks-
 - Andy Badera
 - and...@badera.us
 - Google me: http://www.google.com/search?q=andrew+badera
 - This email is: [ ] bloggable [x] ask first [ ] private



 On Wed, Jul 1, 2009 at 9:25 AM, DWRoelandsduane.roela...@gmail.com
  wrote:

 If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/
 core/1.0#anchor4) states it pretty plainly:

 Service Providers SHOULD NOT rely on the Consumer Secret as a method
 to verify the Consumer identity, unless the Consumer Secret is known
 to be inaccessible to anyone other than the Consumer and the Service
 Provider.

 This is exactly what Twitter has done with the Consumer Secret; they
 rely on it to verify the Consumer identity.

 This is a thorny dilemma for open source developers.  There's no way
 to share the source code without compromising your application's
 security, because you've got to include the Consumer Key Secret in the
 source.  You can obfuscate and encrypt, but a malicious actor with
 access to the source code can simply step through the code until the
 Consumer Secret is exposed in plain text.

 In any event, what's done is done, and Twitter certainly isn't going
 to abandon OAuth at this point.  But opening the source of my Twitter
 client seems to be out of the question if I want to use OAuth.


 On Jul 1, 8:10 am, Philip Plantepplante@gmail.com  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.


 --
 Dossy Shiobara              | do...@panoptic.com | http://dossy.org/
 Panoptic Computer Network   | http://panoptic.com/
  He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on. (p. 70)



[twitter-dev] Re: Security Best Practices

2009-07-04 Thread Duane Roelands
That's certainly a technical possibility.

But I've got to create an authentication scheme for the users to log into my
proxy.
Then I have to set up hosting.
Then I have to write a second application to handle the requests from my
client and send the responses back.
So simply is not an accurate characterization of what's required.

Furthermore, it burdens the users with additional steps (authenticating to
the proxy) that users of closed-source applications don't have to do.

For my project, individual developers will simply have to register for their
own tokens with Twitter.  When I package binaries for end-user distribution,
I'll compile the official keys into the app.  It's not a great solution,
but it will have to do.



On Sat, Jul 4, 2009 at 5:30 AM, Andrew Badera and...@badera.us wrote:


 I haven't done much real desktop OAuth, mostly web ... but can't you
 simply proxy the request through your own server, and keep the secret
 on your server, serving client requests centrally?







[twitter-dev] Re: Security Best Practices

2009-07-04 Thread Dossy Shiobara


On 7/4/09 5:30 AM, Andrew Badera wrote:

I haven't done much real desktop OAuth, mostly web ... but can't you
simply proxy the request through your own server, and keep the secret
on your server, serving client requests centrally?


Yes, yes you can - then you get to enjoy the Twitter rate limit issue 
and having to scale to accomodate concurrent sessions.


The beauty of desktop applications is the decentralized nature, using 
resources close to the user (as opposed to further away on a 
server).  This means scaling per user is built in as the user brings 
their own resources.


OAuth's implicit requirement of funneling everything through a server in 
order to protect a secret is a defect in the design of OAuth, one that 
I've raised on the OAuth mailing lists to which I received the response 
of well, that's not a problem OAuth is trying to solve.  In other 
words: EPIC FAIL.


--
Dossy Shiobara  | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network   | http://panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

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 a...@twitter.com 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 duane.roela...@gmail.com 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 a...@twitter.com 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 duane.roela...@gmail.com
  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 supp...@yourhead.com 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


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Philip Plante

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.

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 duane.roela...@gmail.com 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 a...@twitter.com 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 duane.roela...@gmail.com 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 a...@twitter.com 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 duane.roela...@gmail.com
   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 supp...@yourhead.com 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


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/
core/1.0#anchor4) states it pretty plainly:

Service Providers SHOULD NOT rely on the Consumer Secret as a method
to verify the Consumer identity, unless the Consumer Secret is known
to be inaccessible to anyone other than the Consumer and the Service
Provider.

This is exactly what Twitter has done with the Consumer Secret; they
rely on it to verify the Consumer identity.

This is a thorny dilemma for open source developers.  There's no way
to share the source code without compromising your application's
security, because you've got to include the Consumer Key Secret in the
source.  You can obfuscate and encrypt, but a malicious actor with
access to the source code can simply step through the code until the
Consumer Secret is exposed in plain text.

In any event, what's done is done, and Twitter certainly isn't going
to abandon OAuth at this point.  But opening the source of my Twitter
client seems to be out of the question if I want to use OAuth.


On Jul 1, 8:10 am, Philip Plante pplante@gmail.com 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.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Andrew Badera

The secret should not reside in code. The secret should reside in a
config file, or maybe even a machine datastore. Abstract it out, no
one ever needs to see anything secret in your code.

Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera
- This email is: [ ] bloggable [x] ask first [ ] private



On Wed, Jul 1, 2009 at 9:25 AM, DWRoelandsduane.roela...@gmail.com wrote:

 If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/
 core/1.0#anchor4) states it pretty plainly:

 Service Providers SHOULD NOT rely on the Consumer Secret as a method
 to verify the Consumer identity, unless the Consumer Secret is known
 to be inaccessible to anyone other than the Consumer and the Service
 Provider.

 This is exactly what Twitter has done with the Consumer Secret; they
 rely on it to verify the Consumer identity.

 This is a thorny dilemma for open source developers.  There's no way
 to share the source code without compromising your application's
 security, because you've got to include the Consumer Key Secret in the
 source.  You can obfuscate and encrypt, but a malicious actor with
 access to the source code can simply step through the code until the
 Consumer Secret is exposed in plain text.

 In any event, what's done is done, and Twitter certainly isn't going
 to abandon OAuth at this point.  But opening the source of my Twitter
 client seems to be out of the question if I want to use OAuth.


 On Jul 1, 8:10 am, Philip Plante pplante@gmail.com 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.



[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

That's not correct.  Updates posted to Twitter via Basic Auth always
appear with a source of From Web (unless the application in question
was grandfathered in).  Otherwise, it's not possible to impersonate
another application via Basic Auth.

On Jul 1, 9:34 am, Abraham Williams 4bra...@gmail.com wrote:
 Using basic auth it is already possible to use any
 source and impersonate another application so not much is changing
 here except better security for web applications.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

True, but none of that addresses the central points that I'm trying to
make:

1. The OAuth Core documentation says that providers should not rely on
the Consumer Secret to identify consumers.
2. Twitter's implementation of OAuth appears to do exactly what the
OAuth Core documentation says not to do.
3. As a result, open-source developers have to expose the Consumer
Secret for their application, opening their keys to potential abuse
and eventual cancellation by Twitter.

That's a problem.

What's done is done and I don't expect Twitter to abandon OAuth.  But
it's an important issue that's worth talking about because it's a
security risk for developers of desktop clients.

On Jul 1, 9:50 am, Abraham Williams 4bra...@gmail.com wrote:
 True. But I'm pretty sure that there are more active grandfathered
 sources then OAuth sources. And it takes nothing to create a new OAuth
 application that has the same source as an existing OAuth application
 but with only a slightly different name.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread funkatron

Might sorta work on webapps, or maybe desktop compiled code (assuming
the config is compiled in at build time), but that doesn't help for
desktop apps written in interpreted langs, where all source code and
configs would be easily viewable (although I could imagine some
initial setup stuff where it could get obscured).

Not that I'm on either side of whatever this is.


On Jul 1, 9:32 am, Andrew Badera and...@badera.us wrote:
 The secret should not reside in code. The secret should reside in a
 config file, or maybe even a machine datastore. Abstract it out, no
 one ever needs to see anything secret in your code.

 Thanks-
 - Andy Badera
 - and...@badera.us
 - Google me:http://www.google.com/search?q=andrew+badera
 - This email is: [ ] bloggable [x] ask first [ ] private

 On Wed, Jul 1, 2009 at 9:25 AM, DWRoelandsduane.roela...@gmail.com wrote:

  If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/
  core/1.0#anchor4) states it pretty plainly:

  Service Providers SHOULD NOT rely on the Consumer Secret as a method
  to verify the Consumer identity, unless the Consumer Secret is known
  to be inaccessible to anyone other than the Consumer and the Service
  Provider.

  This is exactly what Twitter has done with the Consumer Secret; they
  rely on it to verify the Consumer identity.

  This is a thorny dilemma for open source developers.  There's no way
  to share the source code without compromising your application's
  security, because you've got to include the Consumer Key Secret in the
  source.  You can obfuscate and encrypt, but a malicious actor with
  access to the source code can simply step through the code until the
  Consumer Secret is exposed in plain text.

  In any event, what's done is done, and Twitter certainly isn't going
  to abandon OAuth at this point.  But opening the source of my Twitter
  client seems to be out of the question if I want to use OAuth.

  On Jul 1, 8:10 am, Philip Plante pplante@gmail.com 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.




[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

Andrew,

The Consumer Secret is the key that has to be associated with my
application so that it can authenticate to Twitter.  Regardless of how
I distribute it, I still have to distribute it with the source code in
order for the source code to work.

No amount of abstraction will prevent someone from analyzing the
source and being able to retrieve the Consumer Secret.

In a closed-source project, this is less of an issue.  For open-source
projects, this is a pretty big problem.

Regards,
Duane

On Jul 1, 9:32 am, Andrew Badera and...@badera.us wrote:
 The secret should not reside in code. The secret should reside in a
 config file, or maybe even a machine datastore. Abstract it out, no
 one ever needs to see anything secret in your code.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Cameron Kaiser

 Yes, but don't distribute it. Obviously config files are human
 readable, but you blank out secrets before publishing them.
 
 People using open source libraries will have to get their own keys.
 So, either you really are contributing in the spirit of open source,
 and you don't care about getting credit, or you're doing it for self
 promotional purposes, and the conversation is moot anyhow.

That's an asinine statement. So everybody who doesn't make their open
source software anonymous is a publicity whore?

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- In memory of John Banner ---


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

Andrew,

I'm not talking about a -library-.  I'm talking about a -client-.  If
I want to produce a Twitter client, it needs its own Consumer Key and
Consumer Key Secret.  If want to share the source code for that
client, I will also have to share it's Consumer Key and Consumer Key
Secret.

You seem to know what you're talking about; perhaps you have a
solution.  I have written a Twitter client.  This client is registered
with Twitter for OAuth.  How do I share the source code without
exposing the Consumer Key Secret and still allow the end users to
authenticate?

Regards,
Duane

On Jul 1, 10:48 am, Andrew Badera and...@badera.us wrote:
 Yes, but don't distribute it. Obviously config files are human
 readable, but you blank out secrets before publishing them.

 People using open source libraries will have to get their own keys.
 So, either you really are contributing in the spirit of open source,
 and you don't care about getting credit, or you're doing it for self
 promotional purposes, and the conversation is moot anyhow.

 You being any person worried about keys and open sourcing their libraries.



 On Wed, Jul 1, 2009 at 10:39 AM, Cameron Kaiserspec...@floodgap.com wrote:

  The secret should not reside in code. The secret should reside in a
  config file, or maybe even a machine datastore. Abstract it out, no
  one ever needs to see anything secret in your code.

  That's not workable. It has to be publicly accessible somehow.

  --
   
  personal:http://www.cameronkaiser.com/--
   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
  -- He hadn't a single redeeming vice. -- Oscar Wilde 
  --


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Cameron Kaiser

 The worst that happens if you publish the consumer tokens in an
 opensouce app is someone malicious uses it to abuse Twitter and the
 consumer token gets banned. At which point you regenerate a new one
 and push a new version of the app. The cycle may or may not start
 again depending on the malicious party.
 
 They can not act upon user accounts without the users going through
 the authorize flow. Using basic auth it is already possible to use any
 source and impersonate another application so not much is changing
 here except better security for web applications.

But the situation you state above is a bigger price to pay than if an
app is impersonated via basic auth. In basic auth, it's simply cosmetic.
In OAuth, you can certainly cause no small amount of turmoil by forcing
open source apps to push out new versions by no fault of their own. That's
not exactly an even playing field.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Man who live in glass house dress in basement. -


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Andrew Badera

Not what I said in the least, but it's interesting that you should
interpret it that way.

Re-read what I said.

If someone is open sourcing something, in the true spirit of open
source, they shouldn't care about getting credit in the source
parameter.

Thanks you and good night, I'm here all week, try the veal, don't
forget to tip your waitresses and angry developers.


On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiserspec...@floodgap.com wrote:

 Yes, but don't distribute it. Obviously config files are human
 readable, but you blank out secrets before publishing them.

 People using open source libraries will have to get their own keys.
 So, either you really are contributing in the spirit of open source,
 and you don't care about getting credit, or you're doing it for self
 promotional purposes, and the conversation is moot anyhow.

 That's an asinine statement. So everybody who doesn't make their open
 source software anonymous is a publicity whore?

 --
  personal: http://www.cameronkaiser.com/ 
 --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
 -- In memory of John Banner 
 ---



[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Cameron Kaiser

 Not what I said in the least, but it's interesting that you should
 interpret it that way.
 
 Re-read what I said.
 
 If someone is open sourcing something, in the true spirit of open
 source, they shouldn't care about getting credit in the source
 parameter.

Tell that to Richard Stallman.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender --


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

Andrew,

This isn't about credit in the source parameter.  It's about
application security.

Twitter has stated that Basic Auth will eventually be deprecated.
OAuth will eventually be the only method of authentication available.
When that happens, developers of open source clients will be forced to
reveal their Consumer Key Secret.

This is a very real problem; open-source developers of desktop clients
will have to reveal their Consumer Key Secret.

Can we keep this discussion focused on the technical issues at hand,
rather than snarking about one another's motives?  It's not
productive.

Regards,
Duane


On Jul 1, 10:57 am, Andrew Badera and...@badera.us wrote:
 Not what I said in the least, but it's interesting that you should
 interpret it that way.

 Re-read what I said.

 If someone is open sourcing something, in the true spirit of open
 source, they shouldn't care about getting credit in the source
 parameter.

 Thanks you and good night, I'm here all week, try the veal, don't
 forget to tip your waitresses and angry developers.



 On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiserspec...@floodgap.com wrote:

  Yes, but don't distribute it. Obviously config files are human
  readable, but you blank out secrets before publishing them.

  People using open source libraries will have to get their own keys.
  So, either you really are contributing in the spirit of open source,
  and you don't care about getting credit, or you're doing it for self
  promotional purposes, and the conversation is moot anyhow.

  That's an asinine statement. So everybody who doesn't make their open
  source software anonymous is a publicity whore?

  --
   
  personal:http://www.cameronkaiser.com/--
   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com
  -- In memory of John Banner 
  ---


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Matt Sanford


Wow, so that's what our development list (and Stallman's name) have  
come to. Please don't make me close this thread. Let's keep is  
friendly and focused.


— Matt

On Jul 1, 2009, at 8:01 AM, Cameron Kaiser wrote:




Not what I said in the least, but it's interesting that you should
interpret it that way.

Re-read what I said.

If someone is open sourcing something, in the true spirit of open
source, they shouldn't care about getting credit in the source
parameter.


Tell that to Richard Stallman.

--
 personal: http://www.cameronkaiser.com/ 
 --

 Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Another visitor. Stay awhile. Stay forever! -- Professor Elvin  
Atombender --




[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Andrew Badera

Amen and thank you Matt.


On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanfordm...@twitter.com wrote:


 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 duane.roela...@gmail.com 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 a...@twitter.com 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 duane.roela...@gmail.com
 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 a...@twitter.com 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 duane.roela...@gmail.com

 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 supp...@yourhead.com 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




[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Abraham Williams

A technical solution I see working is a modified PIN flow where
instead of a 6 digit PIN the user gets a 20 character token that acts
as consumer token. No harder then using PIN flow but each desktop
install would have a unique consumer sub token that could still be
tied into the global consumer token.

Abraham

On Wed, Jul 1, 2009 at 10:11, Andrew Baderaand...@badera.us wrote:

 Amen and thank you Matt.


 On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanfordm...@twitter.com wrote:


 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 duane.roela...@gmail.com 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 a...@twitter.com 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 duane.roela...@gmail.com
 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 a...@twitter.com 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 duane.roela...@gmail.com

 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 supp...@yourhead.com 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






-- 
Abraham Williams | Community Evangelist | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
Project | http://fireeagle.labs.poseurtech.com
This email is: [ ] blogable [x] ask first [ ] private.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Nancy Miracle


Sounds like the assumption is that part of the keypair is in the  
source.  That is clearly a bad idea ... The software should obly  
provide for processes and not ever content


Sent from my iPhone

On Jul 1, 2009, at 11:10 AM, Andrew Badera and...@badera.us wrote:



No one's snarking, but again, interesting you would interpret it  
that way.


Open source all you want, each person deploying an instance will have
to get their own keys. What's so tough about that?



On Wed, Jul 1, 2009 at 11:07 AM,  
DWRoelandsduane.roela...@gmail.com wrote:


Andrew,

This isn't about credit in the source parameter.  It's about
application security.

Twitter has stated that Basic Auth will eventually be deprecated.
OAuth will eventually be the only method of authentication available.
When that happens, developers of open source clients will be forced  
to

reveal their Consumer Key Secret.

This is a very real problem; open-source developers of desktop  
clients

will have to reveal their Consumer Key Secret.

Can we keep this discussion focused on the technical issues at hand,
rather than snarking about one another's motives?  It's not
productive.

Regards,
Duane


On Jul 1, 10:57 am, Andrew Badera and...@badera.us wrote:

Not what I said in the least, but it's interesting that you should
interpret it that way.

Re-read what I said.

If someone is open sourcing something, in the true spirit of open
source, they shouldn't care about getting credit in the source
parameter.

Thanks you and good night, I'm here all week, try the veal, don't
forget to tip your waitresses and angry developers.



On Wed, Jul 1, 2009 at 10:50 AM, Cameron  
Kaiserspec...@floodgap.com wrote:



Yes, but don't distribute it. Obviously config files are human
readable, but you blank out secrets before publishing them.


People using open source libraries will have to get their own  
keys.
So, either you really are contributing in the spirit of open  
source,
and you don't care about getting credit, or you're doing it for  
self

promotional purposes, and the conversation is moot anyhow.


That's an asinine statement. So everybody who doesn't make their  
open

source software anonymous is a publicity whore?



--
 personal:http://www.cameronkaiser.com/--
 Cameron Kaiser * Floodgap Systems *www.floodgap.com*  
ckai...@floodgap.com
-- In memory of John Banner  
---




[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

Nancy,

You're right - it is a bad idea.  However, it appears to be the only
option that Twitter has left to open-source developers who wish to
implement OAuth.  There doesn't seem to be any way around distributing
my application's Consumer Key Secret.

Regards,
Duane


On Jul 1, 11:17 am, Nancy Miracle nmira...@gmail.com wrote:
 Sounds like the assumption is that part of the keypair is in the  
 source.  That is clearly a bad idea ... The software should obly  
 provide for processes and not ever content

 Sent from my iPhone

 On Jul 1, 2009, at 11:10 AM, Andrew Badera and...@badera.us wrote:





  No one's snarking, but again, interesting you would interpret it  
  that way.

  Open source all you want, each person deploying an instance will have
  to get their own keys. What's so tough about that?

  On Wed, Jul 1, 2009 at 11:07 AM,  
  DWRoelandsduane.roela...@gmail.com wrote:

  Andrew,

  This isn't about credit in the source parameter.  It's about
  application security.

  Twitter has stated that Basic Auth will eventually be deprecated.
  OAuth will eventually be the only method of authentication available.
  When that happens, developers of open source clients will be forced  
  to
  reveal their Consumer Key Secret.

  This is a very real problem; open-source developers of desktop  
  clients
  will have to reveal their Consumer Key Secret.

  Can we keep this discussion focused on the technical issues at hand,
  rather than snarking about one another's motives?  It's not
  productive.

  Regards,
  Duane

  On Jul 1, 10:57 am, Andrew Badera and...@badera.us wrote:
  Not what I said in the least, but it's interesting that you should
  interpret it that way.

  Re-read what I said.

  If someone is open sourcing something, in the true spirit of open
  source, they shouldn't care about getting credit in the source
  parameter.

  Thanks you and good night, I'm here all week, try the veal, don't
  forget to tip your waitresses and angry developers.

  On Wed, Jul 1, 2009 at 10:50 AM, Cameron  
  Kaiserspec...@floodgap.com wrote:

  Yes, but don't distribute it. Obviously config files are human
  readable, but you blank out secrets before publishing them.

  People using open source libraries will have to get their own  
  keys.
  So, either you really are contributing in the spirit of open  
  source,
  and you don't care about getting credit, or you're doing it for  
  self
  promotional purposes, and the conversation is moot anyhow.

  That's an asinine statement. So everybody who doesn't make their  
  open
  source software anonymous is a publicity whore?

  --
   
  personal:http://www.cameronkaiser.com/--
   Cameron Kaiser * Floodgap Systems *www.floodgap.com* 
  ckai...@floodgap.com
  -- In memory of John Banner  
  ---


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread JDG
The problem is that by everyone getting their own consumer keys, the source
parameter will be different for every person. Now, I'm not interested in
getting my name in lights in the Twitter world -- I could honestly care
less. That said, if I'm going to spend a significant portion of my time
creating an open source app for people to enjoy, I'd like for people to
actually know that they can use it, and the source parameter is by far the
easiest way to accomplish that.

On Wed, Jul 1, 2009 at 09:10, Andrew Badera and...@badera.us wrote:


 No one's snarking, but again, interesting you would interpret it that way.

 Open source all you want, each person deploying an instance will have
 to get their own keys. What's so tough about that?



 On Wed, Jul 1, 2009 at 11:07 AM, DWRoelandsduane.roela...@gmail.com
 wrote:
 
  Andrew,
 
  This isn't about credit in the source parameter.  It's about
  application security.
 
  Twitter has stated that Basic Auth will eventually be deprecated.
  OAuth will eventually be the only method of authentication available.
  When that happens, developers of open source clients will be forced to
  reveal their Consumer Key Secret.
 
  This is a very real problem; open-source developers of desktop clients
  will have to reveal their Consumer Key Secret.
 
  Can we keep this discussion focused on the technical issues at hand,
  rather than snarking about one another's motives?  It's not
  productive.
 
  Regards,
  Duane
 
 
  On Jul 1, 10:57 am, Andrew Badera and...@badera.us wrote:
  Not what I said in the least, but it's interesting that you should
  interpret it that way.
 
  Re-read what I said.
 
  If someone is open sourcing something, in the true spirit of open
  source, they shouldn't care about getting credit in the source
  parameter.
 
  Thanks you and good night, I'm here all week, try the veal, don't
  forget to tip your waitresses and angry developers.
 
 
 
  On Wed, Jul 1, 2009 at 10:50 AM, Cameron Kaiserspec...@floodgap.com
 wrote:
 
   Yes, but don't distribute it. Obviously config files are human
   readable, but you blank out secrets before publishing them.
 
   People using open source libraries will have to get their own keys.
   So, either you really are contributing in the spirit of open source,
   and you don't care about getting credit, or you're doing it for self
   promotional purposes, and the conversation is moot anyhow.
 
   That's an asinine statement. So everybody who doesn't make their open
   source software anonymous is a publicity whore?
 
   --
    personal:
 http://www.cameronkaiser.com/--
Cameron Kaiser * Floodgap Systems *www.floodgap.com*
 ckai...@floodgap.com
   -- In memory of John Banner
 ---
 




-- 
Internets. Serious business.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

Actually, since Twitter has said that Basic Auth will eventually go
away, OAuth is going to be the only choice for authentication.
Twitter has forced the choice by implementing OAuth in the way that
they did.

Why should a user who chooses to support open source by using an open-
source Twitter client be punished by having to go through extra hoops
that users of closed-source clients don't have to endure?

Forcing users of open source Twitter clients to register their
individual installations as Twitter applications is not a viable
solution.  Matt Sanford has even said so.

No one is asking for easy.  I just want open source Twitter desktop
clients to be able to compete with closed-source versions when it
comes to security.  Right now, that's not possible because of
Twitter's implementation of OAuth.

Regards,
Duane

On Jul 1, 11:23 am, Andrew Badera and...@badera.us wrote:
 But that's the choice you're forced to make by OAuth, not Twitter. And
 it is YOUR choice. Personally, I would probably use the conventional
 mechanisms of open source: mailing lists, special interest and user
 groups. Pound the pavement and promote yourself. Who said it was going
 to be easy?


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Bruce Brown

How difficult is it to, as part of the build, check for a key file, if  
it doesn't exist, go to Twitter and do the stuff to get the tokens,  
parse the tokens and save in the key file, and then continue on with  
the build. Seems easy enuff.

-- Bruce
Sent from my iPhone

On Jul 1, 2009, at 8:23 AM, Andrew Badera and...@badera.us wrote:


 But that's the choice you're forced to make by OAuth, not Twitter. And
 it is YOUR choice. Personally, I would probably use the conventional
 mechanisms of open source: mailing lists, special interest and user
 groups. Pound the pavement and promote yourself. Who said it was going
 to be easy?


 On Wed, Jul 1, 2009 at 11:22 AM, JDGghil...@gmail.com wrote:
 The problem is that by everyone getting their own consumer keys,  
 the source
 parameter will be different for every person. Now, I'm not  
 interested in
 getting my name in lights in the Twitter world -- I could honestly  
 care
 less. That said, if I'm going to spend a significant portion of my  
 time
 creating an open source app for people to enjoy, I'd like for  
 people to
 actually know that they can use it, and the source parameter is by  
 far the
 easiest way to accomplish that.

 On Wed, Jul 1, 2009 at 09:10, Andrew Badera and...@badera.us wrote:

 No one's snarking, but again, interesting you would interpret it  
 that way.

 Open source all you want, each person deploying an instance will  
 have
 to get their own keys. What's so tough about that?



 On Wed, Jul 1, 2009 at 11:07 AM,  
 DWRoelandsduane.roela...@gmail.com
 wrote:

 Andrew,

 This isn't about credit in the source parameter.  It's about
 application security.

 Twitter has stated that Basic Auth will eventually be deprecated.
 OAuth will eventually be the only method of authentication  
 available.
 When that happens, developers of open source clients will be  
 forced to
 reveal their Consumer Key Secret.

 This is a very real problem; open-source developers of desktop  
 clients
 will have to reveal their Consumer Key Secret.

 Can we keep this discussion focused on the technical issues at  
 hand,
 rather than snarking about one another's motives?  It's not
 productive.

 Regards,
 Duane


 On Jul 1, 10:57 am, Andrew Badera and...@badera.us wrote:
 Not what I said in the least, but it's interesting that you should
 interpret it that way.

 Re-read what I said.

 If someone is open sourcing something, in the true spirit of open
 source, they shouldn't care about getting credit in the source
 parameter.

 Thanks you and good night, I'm here all week, try the veal, don't
 forget to tip your waitresses and angry developers.



 On Wed, Jul 1, 2009 at 10:50 AM, Cameron  
 Kaiserspec...@floodgap.com
 wrote:

 Yes, but don't distribute it. Obviously config files are human
 readable, but you blank out secrets before publishing them.

 People using open source libraries will have to get their own  
 keys.
 So, either you really are contributing in the spirit of open  
 source,
 and you don't care about getting credit, or you're doing it  
 for self
 promotional purposes, and the conversation is moot anyhow.

 That's an asinine statement. So everybody who doesn't make  
 their open
 source software anonymous is a publicity whore?

 --
 
 personal:http://www.cameronkaiser.com/--
  Cameron Kaiser * Floodgap Systems *www.floodgap.com*
 ckai...@floodgap.com
 -- In memory of John Banner
 ---




 --
 Internets. Serious business.



[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Matt Sanford


Hello again,

I do not recommend having individual end users register for  
consumer keys/secrets [1] under any circumstances. So, with that out  
of the way, let us focus the discussion a bit more. What can we change  
about OAuth that would make this better? A complete technical [2][3]  
discussion on what we could add that would make this better is  
welcomed. More than welcome, it's pretty much required before we can  
help.
The PIN flow was the first addition to address the inherent  
insecurity of the consumer key/secret all desktop applications [3].  
This stopped applications from being able to collect tokens by using  
the consumer key/secret and a confidence scam (phishing like GoodApp  
needs you to re-approve us). It sounds like there is a fervent need  
for something more … what do people suggest? We're working hard on the  
problem but many of you are working from the consumer standpoint and  
probably have great feedback.
Please, take your time and write a well thought out reply. One- 
line snarky comments, while fun to write and sometimes to read, steal  
time from everyone reading the list, including all of the Twitter API  
engineers. They also make the list look less inviting to new comers.


Thanks;
 – Matt Sanford / @mzsanford
 Twitter Dev

[1] - People installing an instance of your server-side app are not  
'end users', but other developers

[2] - Not open-source hand waving.
[3] - Closed source desktop apps have the same problem. Reverse  
engineering is not stopped when you don't include the source.


On Jul 1, 2009, at 9:33 AM, DWRoelands wrote:



Actually, since Twitter has said that Basic Auth will eventually go
away, OAuth is going to be the only choice for authentication.
Twitter has forced the choice by implementing OAuth in the way that
they did.

Why should a user who chooses to support open source by using an open-
source Twitter client be punished by having to go through extra hoops
that users of closed-source clients don't have to endure?

Forcing users of open source Twitter clients to register their
individual installations as Twitter applications is not a viable
solution.  Matt Sanford has even said so.

No one is asking for easy.  I just want open source Twitter desktop
clients to be able to compete with closed-source versions when it
comes to security.  Right now, that's not possible because of
Twitter's implementation of OAuth.

Regards,
Duane

On Jul 1, 11:23 am, Andrew Badera and...@badera.us wrote:
But that's the choice you're forced to make by OAuth, not Twitter.  
And

it is YOUR choice. Personally, I would probably use the conventional
mechanisms of open source: mailing lists, special interest and user
groups. Pound the pavement and promote yourself. Who said it was  
going

to be easy?




[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

I'm not sure that Twitter exposes any API or web service that allows
you to programatically register a new application (which you need to
do to receive the Consumer Key and Consumer Key Secret).

Even if you could, that still requires the end user to compile the
source with a modified build process.  Requiring Windows users to
compile source code in order to use the app is not a great solution.

Any solution to the problem should be as transparent to the user as
possible.  They shouldn't be burdened with extra steps or procedures
because they chose an open source client.


On Jul 1, 12:39 pm, Bruce Brown bruce1...@cox.net wrote:
 How difficult is it to, as part of the build, check for a key file, if  
 it doesn't exist, go to Twitter and do the stuff to get the tokens,  
 parse the tokens and save in the key file, and then continue on with  
 the build. Seems easy enuff.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Abraham Williams

I think this got lost under all the mess:

On Wed, Jul 1, 2009 at 10:15, Abraham Williams4bra...@gmail.com wrote:
 A technical solution I see working is a modified PIN flow where
 instead of a 6 digit PIN the user gets a 20 character token that acts
 as consumer token. No harder then using PIN flow but each desktop
 install would have a unique consumer sub token that could still be
 tied into the global consumer token.

 Abraham



-- 
Abraham Williams | Community Evangelist | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
Project | http://fireeagle.labs.poseurtech.com
This email is: [ ] blogable [x] ask first [ ] private.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread DWRoelands

Mark,

Thanks for weighing in.  Much appreciated.  Here are my thoughts.

I see two separate issues here: User Authentication vs. Application
Authentication.

User Authentication: Ensuring that the Twitter user is who they say
they are.
Application Authentication: Ensuring that the Application is who it
says it is (i.e. the tweet is really coming from TweetDeck and not
some other application pretending to be TweetDeck).

User Authentication:
I understand that Basic Auth, as is, is not a secure solution.
Transmitting unencrypted credentials in the clear is never a great
idea.  What about combining Basic Auth with a form of public/private
key encryption?  Using PGP as an example, Twitter could publish it's
public PGP key.  Applications using Basic Auth would have to encrypt
the username and password with that key and submit the encrypted
username and password as the Basic Auth credentials.  Twitter decrypts
them server side and processes authentication normally.  Developers
wouldn't have to include any sensitive information in their source
code, and the credentials would always be transmitted in an encrypted
fashion.  PGP is a fairly robust standard, with lots of free resources
available to the development community across many languages.

Application Authentication:
This is a thornier issue that I'm not sure how to solve without having
to bundle some sort of sensitive information in the source code of an
application.  However, I think the issue becomes more manageable if
User Authentication is separated from Application Authentication.

I have no doubt that many of the folks on this list have good ideas on
how to solve the second problem.

Thoughts

Regards,
Duane

On Jul 1, 12:46 pm, Matt Sanford m...@twitter.com wrote:

      Please, take your time and write a well thought out reply. One-
 line snarky comments, while fun to write and sometimes to read, steal  
 time from everyone reading the list, including all of the Twitter API  
 engineers. They also make the list look less inviting to new comers.


[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Support


Matt,

Thanks for weighing in and hopefully taming this snarl.  As the person  
who might have posed the question originally, I figured I at least  
owed a bit of constructive critique.



What can we change about OAuth that would make this better?


1) User experience - it's been echoed a number of times in this board,  
so i won't beat the dead horse...   much...but basic auth *is*  
much simpler for the user.
The reason is obvious:  oauth requires a browser. In many platforms  
(especially mobile) that's a painful burden.


The PIN code seems to be ignoring the elephant in the room.  It solves  
some problems, but at a further cost to the user experience, giving an  
even larger advantage to existing basic-auth apps.
You've made the pill even more effective, but so bitter that your  
patients can't swallow it.


Providing a scheme that does not require a browser is an obvious way  
to cut this gordian knot.



2) Application authentication - if your goal is to *identify* each  
open source application in a *trusted* way, then I think you could be  
in for an uphill battle.  There are obvious technical challenges,  
however the larger problem is that in OSS there is no way to define  
each application.  There will be many binaries for different  
platforms and people will fork it on github just because they can.   
You cannot identify each of these variants as the same when they could  
be different.


And that places a burden on the user experience.  When a user grants  
access to application x -- what does that mean exactly?  Just that  
binary?  Just this release?  Only from a specific trusted company?   
How do you explain to the user where this subtle line is drawn in a  
box he'll click through in less than a second?


I personally don't see an obvious solution to this problem.  It seems  
to be a UI challenge and a technical challenge.  In cases like that it  
seems prudent to question your goals and check feasibility.



Isaiah

YourHead Software
supp...@yourhead.com
http://www.yourhead.com



On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote:



Hello again,

   I do not recommend having individual end users register for  
consumer keys/secrets [1] under any circumstances. So, with that out  
of the way, let us focus the discussion a bit more. What can we  
change about OAuth that would make this better? A complete technical  
[2][3] discussion on what we could add that would make this better  
is welcomed. More than welcome, it's pretty much required before we  
can help.
   The PIN flow was the first addition to address the inherent  
insecurity of the consumer key/secret all desktop applications [3].  
This stopped applications from being able to collect tokens by using  
the consumer key/secret and a confidence scam (phishing like  
GoodApp needs you to re-approve us). It sounds like there is a  
fervent need for something more … what do people suggest? We're  
working hard on the problem but many of you are working from the  
consumer standpoint and probably have great feedback.
   Please, take your time and write a well thought out reply. One- 
line snarky comments, while fun to write and sometimes to read,  
steal time from everyone reading the list, including all of the  
Twitter API engineers. They also make the list look less inviting to  
new comers.


Thanks;
– Matt Sanford / @mzsanford
Twitter Dev

[1] - People installing an instance of your server-side app are not  
'end users', but other developers

[2] - Not open-source hand waving.
[3] - Closed source desktop apps have the same problem. Reverse  
engineering is not stopped when you don't include the source.


On Jul 1, 2009, at 9:33 AM, DWRoelands wrote:



Actually, since Twitter has said that Basic Auth will eventually go
away, OAuth is going to be the only choice for authentication.
Twitter has forced the choice by implementing OAuth in the way that
they did.

Why should a user who chooses to support open source by using an  
open-

source Twitter client be punished by having to go through extra hoops
that users of closed-source clients don't have to endure?

Forcing users of open source Twitter clients to register their
individual installations as Twitter applications is not a viable
solution.  Matt Sanford has even said so.

No one is asking for easy.  I just want open source Twitter desktop
clients to be able to compete with closed-source versions when it
comes to security.  Right now, that's not possible because of
Twitter's implementation of OAuth.

Regards,
Duane

On Jul 1, 11:23 am, Andrew Badera and...@badera.us wrote:
But that's the choice you're forced to make by OAuth, not Twitter.  
And

it is YOUR choice. Personally, I would probably use the conventional
mechanisms of open source: mailing lists, special interest and user
groups. Pound the pavement and promote yourself. Who said it was  
going

to be easy?






[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Neil Ellis
On a completely separate note, your website is stunning, did you  
design it yourself? If not may I ask who were your designers.

All the best
Neil
http://www.peepwl.com

On 1 Jul 2009, at 20:22, Support wrote:


 Matt,

 Thanks for weighing in and hopefully taming this snarl.  As the  
 person who might have posed the question originally, I figured I at  
 least owed a bit of constructive critique.

 What can we change about OAuth that would make this better?

 1) User experience - it's been echoed a number of times in this  
 board, so i won't beat the dead horse...   much...but basic auth  
 *is* much simpler for the user.
 The reason is obvious:  oauth requires a browser. In many platforms  
 (especially mobile) that's a painful burden.

 The PIN code seems to be ignoring the elephant in the room.  It  
 solves some problems, but at a further cost to the user experience,  
 giving an even larger advantage to existing basic-auth apps.
 You've made the pill even more effective, but so bitter that your  
 patients can't swallow it.

 Providing a scheme that does not require a browser is an obvious way  
 to cut this gordian knot.


 2) Application authentication - if your goal is to *identify* each  
 open source application in a *trusted* way, then I think you could  
 be in for an uphill battle.  There are obvious technical challenges,  
 however the larger problem is that in OSS there is no way to define  
 each application.  There will be many binaries for different  
 platforms and people will fork it on github just because they can.   
 You cannot identify each of these variants as the same when they  
 could be different.

 And that places a burden on the user experience.  When a user grants  
 access to application x -- what does that mean exactly?  Just that  
 binary?  Just this release?  Only from a specific trusted company?   
 How do you explain to the user where this subtle line is drawn in a  
 box he'll click through in less than a second?

 I personally don't see an obvious solution to this problem.  It  
 seems to be a UI challenge and a technical challenge.  In cases like  
 that it seems prudent to question your goals and check feasibility.


 Isaiah

 YourHead Software
 supp...@yourhead.com
 http://www.yourhead.com



 On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote:


 Hello again,

I do not recommend having individual end users register for  
 consumer keys/secrets [1] under any circumstances. So, with that  
 out of the way, let us focus the discussion a bit more. What can we  
 change about OAuth that would make this better? A complete  
 technical [2][3] discussion on what we could add that would make  
 this better is welcomed. More than welcome, it's pretty much  
 required before we can help.
The PIN flow was the first addition to address the inherent  
 insecurity of the consumer key/secret all desktop applications [3].  
 This stopped applications from being able to collect tokens by  
 using the consumer key/secret and a confidence scam (phishing like  
 GoodApp needs you to re-approve us). It sounds like there is a  
 fervent need for something more … what do people suggest? We're  
 working hard on the problem but many of you are working from the  
 consumer standpoint and probably have great feedback.
Please, take your time and write a well thought out reply. One- 
 line snarky comments, while fun to write and sometimes to read,  
 steal time from everyone reading the list, including all of the  
 Twitter API engineers. They also make the list look less inviting  
 to new comers.

 Thanks;
 – Matt Sanford / @mzsanford
 Twitter Dev

 [1] - People installing an instance of your server-side app are not  
 'end users', but other developers
 [2] - Not open-source hand waving.
 [3] - Closed source desktop apps have the same problem. Reverse  
 engineering is not stopped when you don't include the source.

 On Jul 1, 2009, at 9:33 AM, DWRoelands wrote:


 Actually, since Twitter has said that Basic Auth will eventually go
 away, OAuth is going to be the only choice for authentication.
 Twitter has forced the choice by implementing OAuth in the way that
 they did.

 Why should a user who chooses to support open source by using an  
 open-
 source Twitter client be punished by having to go through extra  
 hoops
 that users of closed-source clients don't have to endure?

 Forcing users of open source Twitter clients to register their
 individual installations as Twitter applications is not a viable
 solution.  Matt Sanford has even said so.

 No one is asking for easy.  I just want open source Twitter  
 desktop
 clients to be able to compete with closed-source versions when it
 comes to security.  Right now, that's not possible because of
 Twitter's implementation of OAuth.

 Regards,
 Duane

 On Jul 1, 11:23 am, Andrew Badera and...@badera.us wrote:
 But that's the choice you're forced to make by OAuth, not  
 Twitter. And
 it is YOUR choice. Personally, I 

[twitter-dev] Re: Security Best Practices

2009-07-01 Thread Matt Sanford



On Jul 1, 2009, at 10:17 AM, DWRoelands wrote:



Mark,

Thanks for weighing in.  Much appreciated.  Here are my thoughts.

I see two separate issues here: User Authentication vs. Application
Authentication.

User Authentication: Ensuring that the Twitter user is who they say
they are.
Application Authentication: Ensuring that the Application is who it
says it is (i.e. the tweet is really coming from TweetDeck and not
some other application pretending to be TweetDeck).

User Authentication:
I understand that Basic Auth, as is, is not a secure solution.
Transmitting unencrypted credentials in the clear is never a great
idea.  What about combining Basic Auth with a form of public/private
key encryption?  Using PGP as an example, Twitter could publish it's
public PGP key.  Applications using Basic Auth would have to encrypt
the username and password with that key and submit the encrypted
username and password as the Basic Auth credentials.  Twitter decrypts
them server side and processes authentication normally.  Developers
wouldn't have to include any sensitive information in their source
code, and the credentials would always be transmitted in an encrypted
fashion.  PGP is a fairly robust standard, with lots of free resources
available to the development community across many languages.


Rather than breaking with the HTTP specification for Basic  
authentication we offer HTTP over SSL for encrypted access. That adds  
the benefits you enumerate above plus:


 * Requires very little coding from developers (most libraries  
support it)

 * Built on an open standard
 * Prevents re-using an Authentication header (even one encrypted) to  
essentially act like a user.
 * Bonus: Encrypts the contents so nobody else is reading your DMs on  
the wire




Application Authentication:
This is a thornier issue that I'm not sure how to solve without having
to bundle some sort of sensitive information in the source code of an
application.  However, I think the issue becomes more manageable if
User Authentication is separated from Application Authentication.


This seems to be the crux of the issue from what I can tell. Isaiah  
from youhead enumerated some of the difficulties with that, especially  
for open source.




I have no doubt that many of the folks on this list have good ideas on
how to solve the second problem.

Thoughts

Regards,
Duane

On Jul 1, 12:46 pm, Matt Sanford m...@twitter.com wrote:


 Please, take your time and write a well thought out reply. One-
line snarky comments, while fun to write and sometimes to read, steal
time from everyone reading the list, including all of the Twitter API
engineers. They also make the list look less inviting to new comers.




[twitter-dev] Re: Security Best Practices

2009-06-30 Thread DWRoelands

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 supp...@yourhead.com wrote:
 2.  Obfuscation of the application's registered key and secret.
 Are there any best practices?  What about an open source project?


[twitter-dev] Re: Security Best Practices

2009-06-30 Thread Alex Payne
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
at http://groups.google.com/group/oauth

On Tue, Jun 30, 2009 at 06:04, DWRoelands duane.roela...@gmail.com 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 supp...@yourhead.com 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


[twitter-dev] Re: Security Best Practices

2009-06-30 Thread DWRoelands

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 a...@twitter.com 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 duane.roela...@gmail.com 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 supp...@yourhead.com 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


[twitter-dev] Re: Security Best Practices

2009-06-30 Thread Alex Payne
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 duane.roela...@gmail.com 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 a...@twitter.com 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 duane.roela...@gmail.com
 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 supp...@yourhead.com 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


[twitter-dev] Re: Security Best Practices

2009-06-29 Thread Scott Haneda


I heard the other day that in the wake of the MJ stuff, a few high  
profile celebs accounts where hacked.  Is this media hacking and  
there were just weak passwords, or their email accounts were  
compromised, or were these real live hacks where someone brute forced,  
or did otherwise nefarious acts to get in.


Some clarification on these events would help to let us know where and  
how people are getting in, so we can tighten things up on our end. If  
the hacks are just email accounts being gotten into, there is nothing  
twitter apps need to do.  If it is something else, there may be other  
things we can do to keep the accounts safe.


Thanks.

On Jun 29, 2009, at 3:34 PM, Alex Payne wrote:

I wanted to point out a blog post (http://apiblog.twitter.com/security-best-practices-for-twitter-apps 
) that addresses the coming Month of Twitter Bugs. Long story  
short: Twitter is in the loop, we've got security at the forefront  
of our daily work right now, and we're available to help if your  
application is identified as vulnerable or compromised.


Please check out the new wiki page (http://apiwiki.twitter.com/Security-Best-Practices 
) and let us know what's missing. Thanks!


--
Scott * If you contact me off list replace talklists@ with scott@ *



[twitter-dev] Re: Security Best Practices

2009-06-29 Thread Scott Haneda


Got to love these headlines:
http://mashable.com/2009/06/28/britney-spears-dead/

They clearly point the finger at twitter in the headline, but reading  
on, and it is clearly a twit pic issue.


I see these all over the place.  Have you considered some sort of  
vetting system for sites that are asking for twitter credentials on a  
3rd party site?


I can see that twitpic may not be able to use o-auth, as they want to  
be able to stand alone and a image host.  If there was some sort of  
communication where you worked with the large sites like twit pic, it  
may help.  As it is now, I fell for it, I read the headline, and  
thought ti was a twitter issue.


Just some food for thought.

On Jun 29, 2009, at 3:54 PM, Alex Payne wrote:

Any recent celebrity-related compromises I'm aware of having been,  
as you
said, media 'hacking'. The last issue I'm aware of that resulted  
from
actually taking advantage of a security flaw in our system was the  
Mikeyy
worm that was going around for a weekend several months ago. We've  
done a

lot of security work since then, and there's more in progress.

On Mon, Jun 29, 2009 at 15:40, Scott Haneda talkli...@newgeo.com  
wrote:




I heard the other day that in the wake of the MJ stuff, a few high  
profile
celebs accounts where hacked.  Is this media hacking and there  
were just
weak passwords, or their email accounts were compromised, or were  
these real
live hacks where someone brute forced, or did otherwise nefarious  
acts to

get in.

Some clarification on these events would help to let us know where  
and how
people are getting in, so we can tighten things up on our end. If  
the hacks
are just email accounts being gotten into, there is nothing twitter  
apps
need to do.  If it is something else, there may be other things we  
can do to

keep the accounts safe.


--
Scott * If you contact me off list replace talklists@ with scott@ *



[twitter-dev] Re: Security Best Practices

2009-06-29 Thread Scott Haneda


As a separate issue, I would like to talk about privacy on twitter.   
If this is the wrong place for this, let me know.


Twitter asks for my email address when I signed up.  I put some pretty  
stupid junk in my twitter account, and I thought I was anonymous.   
Somehow, many people I associate with are finding me, putting me in a  
bit of a bind.


I learned later on, by importing my personal address book into gmail,  
I can login to gmail via twitter, and find all sorts of people.


This is not explained anywhere that I can tell, that my email address  
can be used as a vector to locate me within twitter.  With this, as  
long as I use my real email address, I have no anonymity on twitter.


What are you comments on this?  I know I can change my email address,  
and I will shortly.  Though I overlooked this, and it took me some  
time to figure out how people were finding me so easily.

--
Scott * If you contact me off list replace talklists@ with scott@ *



[twitter-dev] Re: Security Best Practices

2009-06-29 Thread Alex Payne
Any recent celebrity-related compromises I'm aware of having been, as you
said, media 'hacking'. The last issue I'm aware of that resulted from
actually taking advantage of a security flaw in our system was the Mikeyy
worm that was going around for a weekend several months ago. We've done a
lot of security work since then, and there's more in progress.

On Mon, Jun 29, 2009 at 15:40, Scott Haneda talkli...@newgeo.com wrote:


 I heard the other day that in the wake of the MJ stuff, a few high profile
 celebs accounts where hacked.  Is this media hacking and there were just
 weak passwords, or their email accounts were compromised, or were these real
 live hacks where someone brute forced, or did otherwise nefarious acts to
 get in.

 Some clarification on these events would help to let us know where and how
 people are getting in, so we can tighten things up on our end. If the hacks
 are just email accounts being gotten into, there is nothing twitter apps
 need to do.  If it is something else, there may be other things we can do to
 keep the accounts safe.

 Thanks.

 On Jun 29, 2009, at 3:34 PM, Alex Payne wrote:

  I wanted to point out a blog post (
 http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that
 addresses the coming Month of Twitter Bugs. Long story short: Twitter is
 in the loop, we've got security at the forefront of our daily work right
 now, and we're available to help if your application is identified as
 vulnerable or compromised.

 Please check out the new wiki page (
 http://apiwiki.twitter.com/Security-Best-Practices) and let us know
 what's missing. Thanks!


 --
 Scott * If you contact me off list replace talklists@ with scott@ *




-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Security Best Practices

2009-06-29 Thread Alex Payne
We're in contact with TwitPic's developer, and we reach out to developers
with security issues. We want to keep the barrier to entry as low as
possible on the Twitter platform, and a vetting system doesn't dovetail with
that philosophy.

On Mon, Jun 29, 2009 at 16:03, Scott Haneda talkli...@newgeo.com wrote:


 Got to love these headlines:
 http://mashable.com/2009/06/28/britney-spears-dead/

 They clearly point the finger at twitter in the headline, but reading on,
 and it is clearly a twit pic issue.

 I see these all over the place.  Have you considered some sort of vetting
 system for sites that are asking for twitter credentials on a 3rd party
 site?

 I can see that twitpic may not be able to use o-auth, as they want to be
 able to stand alone and a image host.  If there was some sort of
 communication where you worked with the large sites like twit pic, it may
 help.  As it is now, I fell for it, I read the headline, and thought ti was
 a twitter issue.

 Just some food for thought.

 On Jun 29, 2009, at 3:54 PM, Alex Payne wrote:

  Any recent celebrity-related compromises I'm aware of having been, as you
 said, media 'hacking'. The last issue I'm aware of that resulted from
 actually taking advantage of a security flaw in our system was the
 Mikeyy
 worm that was going around for a weekend several months ago. We've done a
 lot of security work since then, and there's more in progress.

 On Mon, Jun 29, 2009 at 15:40, Scott Haneda talkli...@newgeo.com wrote:


 I heard the other day that in the wake of the MJ stuff, a few high
 profile
 celebs accounts where hacked.  Is this media hacking and there were
 just
 weak passwords, or their email accounts were compromised, or were these
 real
 live hacks where someone brute forced, or did otherwise nefarious acts to
 get in.

 Some clarification on these events would help to let us know where and
 how
 people are getting in, so we can tighten things up on our end. If the
 hacks
 are just email accounts being gotten into, there is nothing twitter apps
 need to do.  If it is something else, there may be other things we can do
 to
 keep the accounts safe.


 --
 Scott * If you contact me off list replace talklists@ with scott@ *




-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x


[twitter-dev] Re: Security Best Practices

2009-06-29 Thread Support
Hi Alex,I just thought I'd give you some feedback onthe"DesktopApplicationSecurity"sectionhere:http://apiwiki.twitter.com/Security-Best-Practices#DesktopApplicationSecurityBoth of the sections below seem to be subheadings under this topic:

pastedGraphic.pdf
Description: Adobe PDF document
1. Under this heading the sub-sectionofthe documenttitled"LackofRateLimiting" states that we should use a "CAPTCHA" to slow down hackers. This didn't make much sense to me as when I think of Desktop Application I think of the few that I've used: Twitteriffic, Tweetie, and Destroy Twitter. All of those have direct control of their UI. Although a CAPTCHA could be used to limit scripted behaviors, it would probably be more effective just to directly limit the resource.It's not that a CAPTCHA *couldn't* be used, it's just not something I see very often in a desktop application.It seems to me that CAPTCHA would be more appropriate for a multi-user service than a single user desktop app -- so I was wondering if this section of the document was in the wrong area.2. Under the sub-section Lack of Information about Threats, it begins, "If you think there's an issue with your web application, how do you find out for sure?" This is clearly at least a typo in the *desktop* app section, but itgoes on to describe creating a "dashboard" of critical stats. Again,thiswouldmake more senseinthecontextof service administrator,but I'm having trouble understanding what this would mean to a desktop application developer.Am I misunderstanding what is meant by "Desktop Application?" Does that mean something other than the examples I mentioned?Thanks,IsaiahYourHead Softwaresupp...@yourhead.comhttp://www.yourhead.comOn Jun 29, 2009, at 3:34 PM, Alex Payne wrote:I wanted to point out a blog post (http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that addresses the coming "Month of Twitter Bugs". Long story short: Twitter is in the loop, we've got security at the forefront of our daily work right now, and we're available to help if your application is identified as vulnerable or compromised.Please check out the new wiki page (http://apiwiki.twitter.com/Security-Best-Practices) and let us know what's missing. Thanks! -- Alex Payne - Platform Lead, Twitter, Inc.http://twitter.com/al3x

[twitter-dev] Re: Security Best Practices

2009-06-29 Thread Alex Payne
Apologies, these two sections were under the wrong heading.

On Mon, Jun 29, 2009 at 16:32, Support supp...@yourhead.com wrote:


 Hi Alex,
 I just thought I'd give you some feedback
 on the Desktop Application Security section here:

 http://apiwiki.twitter.com/Security-Best-Practices#DesktopApplicationSecurity

 Both of the sections below seem to be subheadings under this topic:





 1.  Under this heading the sub-section of the
 document titled Lack of Rate Limiting states that we should use a
 CAPTCHA to slow down hackers.  This didn't make much sense to me as when I
 think of Desktop Application I think of the few that I've used:
  Twitteriffic, Tweetie, and Destroy Twitter.  All of those have direct
 control of their UI.  Although a CAPTCHA could be used to limit scripted
 behaviors, it would probably be more effective just to directly limit the
 resource.
 It's not that a CAPTCHA *couldn't* be used, it's just not something I see
 very often in a desktop application.
 It seems to me that CAPTCHA would be more appropriate for a multi-user
 service than a single user desktop app -- so I was wondering if this section
 of the document was in the wrong area.

 2.  Under the sub-section Lack of Information about Threats, it begins, If
 you think there's an issue with your web application, how do you find out
 for sure?  This is clearly at least a typo in the *desktop* app section,
 but it goes on to describe creating a dashboard of critical stats.
  Again, this would make more sense in the context of service
 administrator, but I'm having trouble understanding what this would mean to
 a desktop application developer.


 Am I misunderstanding what is meant by Desktop Application?  Does that
 mean something other than the examples I mentioned?


 Thanks,

 Isaiah

 YourHead Software
 supp...@yourhead.com
 http://www.yourhead.com



 On Jun 29, 2009, at 3:34 PM, Alex Payne wrote:

 I wanted to point out a blog post (
 http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that
 addresses the coming Month of Twitter Bugs. Long story short: Twitter is
 in the loop, we've got security at the forefront of our daily work right
 now, and we're available to help if your application is identified as
 vulnerable or compromised.
 Please check out the new wiki page (
 http://apiwiki.twitter.com/Security-Best-Practices) and let us know what's
 missing. Thanks!

 --
 Alex Payne - Platform Lead, Twitter, Inc.
 http://twitter.com/al3x






-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x