[twitter-dev] Re: Security Best Practices
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 Shiobara 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
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
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 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
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 Shiobara 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, DWRoelands >> 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 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
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, DWRoelands 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 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
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 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
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
[twitter-dev] Re: Security Best Practices
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 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
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 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
I think this got lost under all the mess: On Wed, Jul 1, 2009 at 10:15, Abraham Williams<4bra...@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
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 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
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 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
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 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, JDG 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 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, >>> DWRoelands >>> 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 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 > Kaiser > 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
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 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
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, JDG 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 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, DWRoelands >> 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 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 Kaiser >> >> 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
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 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, DWRoelands > 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 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 Kaiser > 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
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 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 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, > > DWRoelands 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 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 > >>> Kaiser 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
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 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, DWRoelands 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 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 Kaiser 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
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 Badera wrote: > > Amen and thank you Matt. > > > On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanford 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 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 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 > 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 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 >> >> 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 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://fireea
[twitter-dev] Re: Security Best Practices
Amen and thank you Matt. On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanford 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 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 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 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 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 > > 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 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
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
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, DWRoelands 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 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 Kaiser 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
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 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 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 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 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 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 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
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 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 Kaiser 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
> 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
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 Kaiser 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
> 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
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 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 Kaiser 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
There's a difference between sending out an open source library and an open source APPLICATION, which requires a key be used for identification and source. On Wed, Jul 1, 2009 at 08:48, Andrew Badera 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 Kaiser > 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 > -- > > > -- Internets. Serious business.
[twitter-dev] Re: Security Best Practices
> 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
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 Kaiser 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
> 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
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 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
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 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, DWRoelands 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 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
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
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. Abraham On Wed, Jul 1, 2009 at 08:39, DWRoelands wrote: > > 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. > -- 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
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
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. Abraham On Wed, Jul 1, 2009 at 08:25, DWRoelands 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 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. > -- 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
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, DWRoelands 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 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
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 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
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 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 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 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 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 > > > 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 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
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 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 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 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 > > 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 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
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 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 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 > 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 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
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 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 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 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
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 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 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
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 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
Thanks for the quick change. Nothing like real-time updates! But I'll take you up on your querry: We could use suggestions from desktop developers about the security issues they've run into. Developers working in sufficiently high- level languages shouldn't be dealing with buffer overflows and the usual security issues. What have you defended against? Off the top of my head, it seems like the two things I put the most thought into were: 1. Storage of access keys (for OAUTH) or passwords (for basic auth). Since an access key provides nearly as many rights as a username/ password pair, it has just as much power if it is acquired by an untrusted 3rd party. In Mac OS X the "Keychain" is the home of data that must be stored in an encrypted form and accessed through a secure API. I'm not sure what AIR, Silverlight, or Windows devs are conquering this subject. I imagine each platform has a set of best practices. But it would probably be a good idea to at least mention the gravity of secure storage of these things. Since OAuth keys are new to a lot of us, I can see someone accidentally misunderstanding this and storing them in a preference file unprotected. 2. Obfuscation of the application's registered "key" and "secret." Are there any best practices? What about an open source project? Isaiah YourHead Software supp...@yourhead.com http://www.yourhead.com On Jun 29, 2009, at 4:40 PM, Alex Payne wrote: Apologies, these two sections were under the wrong heading. On Mon, Jun 29, 2009 at 16:32, Support 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
[twitter-dev] Re: Security Best Practices
Apologies, these two sections were under the wrong heading. On Mon, Jun 29, 2009 at 16:32, Support 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
[twitter-dev] Re: Security Best Practices
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#DesktopApplicationSecurityBoth of the sections below seem to be subheadings under this topic: pastedGraphic.pdf Description: Adobe PDF document 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,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
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 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 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
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 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
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
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 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
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@ *
