[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 ...

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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. --

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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]

[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

[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

[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

[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

[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

[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.

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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.

[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: