Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
c. The Streaming API isn't designed to play well with desktops / laptops / mobiles. (not to change the direction of the thread) just out of curiosity - why do you think that's the case? we don't intend it not to play well, and want to know what you think should be fixed. The environment in which Twitter and the Twitter development community operate is changing rapidly. The *desktop* oAuth tradeoffs may have made sense a year ago. before the huge growth spurt in awareness and usage of Twitter in 2009. As I've noted, I think the *server* oAuth tradeoffs still make sense. I think we need to take the advice of Wayne Gretzky and skate to where the puck is going to be. i just want to really emphasize that we all do energetically read these email threads and try to learn as much as we can from them. this thread, so far, has been great. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
* Raffi Krikorian ra...@twitter.com [100201 07:36]: c. The Streaming API isn't designed to play well with desktops / laptops / mobiles. (not to change the direction of the thread) just out of curiosity - why do you think that's the case? we don't intend it not to play well, and want to know what you think should be fixed. As I understand it, the Streaming API uses only Basic Authentication *without* SSL. That frightens me. It means anyone who can sniff traffic at the hosting site I use can hijack the account I use for Streaming API access. Now that the Streaming API is no longer beta, will Twitter be providing some more secure mechanism for authenticating? -Marc
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On Mon, Feb 1, 2010 at 7:36 AM, Raffi Krikorian ra...@twitter.com wrote: c. The Streaming API isn't designed to play well with desktops / laptops / mobiles. (not to change the direction of the thread) just out of curiosity - why do you think that's the case? we don't intend it not to play well, and want to know what you think should be fixed. My choice of words was wrong. I don't remember the exact language - I can find it if necessary - but when the Streaming API was released to production status, John Kalucki said that desktop developers should hold off on production use of Streaming but that it was OK to test with it. But Streaming is a steady, hopefully uninterrupted flow of tweets. Those have to be buffered / persisted for at least some length of time for them to be useful beyond just displaying breaking news. Mobiles don't have the space and have limited memory and processing capabilities. And if they're going to be always on and always collecting / processing data, they have to be plugged in. I can see a case for building a desktop app with Streaming, provided you have a backup mechanism for data collection in case your desktop needs to be rebooted. But laptops are essentially the same deal as mobiles - they aren't always plugged in to a power source. The environment in which Twitter and the Twitter development community operate is changing rapidly. The *desktop* oAuth tradeoffs may have made sense a year ago. before the huge growth spurt in awareness and usage of Twitter in 2009. As I've noted, I think the *server* oAuth tradeoffs still make sense. I think we need to take the advice of Wayne Gretzky and skate to where the puck is going to be. i just want to really emphasize that we all do energetically read these email threads and try to learn as much as we can from them. this thread, so far, has been great. I've said this before, but maybe not here. As a developer I've worked with a number of companies over the years, and I can't think of any that was easier to work with than Twitter. Part of it is the simplicity of the API - have a look at Google's or Facebook's some time. ;-) But a bigger part is that you do understand what our challenges are. It's not just oAuth and it's not just Twitter - mobile and desktop security is a big challenge. Microsoft has been unable to stop the spread of botnets on Windows, and only the relative rarity of Mac and Linux desktops has prevented them from becoming botnet targets as well. Google's idea of a locked-down netbook that can't be compromised without a screwdriver and a soldering iron is looking very good to me right now. ;-) -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Using a proxy to handle all requests is not that simple. You need both consumer and access secrets to sign the request. http://groups.google.co.in/group/twitter-development-talk/browse_thread/thread/a195ea9b9952e297/851d9b34ecc9126f?q=#851d9b34ecc9126f You have to handle the burden of securely mapping user request from your desktop app to get his access token with in the proxy. I would rather prefer distributing them either as obfuscated or through secure proxy (just to fetch consumer key/secret once). None of them is 100% safe but it is slightly better than simply giving away your keys in plain text. On Sun, Jan 31, 2010 at 8:07 AM, ShellEx Well 5h3l...@gmail.com wrote: I have considered this matter. But to use a proxy handle all request is not my intention... I will go to write a online version if i have to do that :D. What I want to know is that: in my distributed version, should I include the key/secret in the config file(or hardcode in source, it doesn't matter)? On Jan 31, 8:42 am, Josh Roesslein jroessl...@gmail.com wrote: I suppose the only other way to make the UX good and to keep the consumer secret absolutely hidden is to proxy all requests through a hosted server. This does come as a cost of having to pay for a server to perform the proxy work. But it's really the only option at the moment I can think of that's 100% safe. Josh On Sat, Jan 30, 2010 at 6:35 PM, funkatron funkat...@gmail.com wrote: Not to be a complete pill, but that is a terrible, terrible initial experience for the average desktop app user. There is no way I would or could reasonably ask one of my users to register an app themselves, then fill in obscure hashes. The OAuth secret is simply impossible to use securely with open source, end-user-oriented applications. My only option with Spaz, when Twitter decides to take away basic auth, is to pray someone doesn't decide to steal my secret hash. Compiling does make getting the key more difficult, but assuming that desktop apps are compiled isn't a good idea -- Spaz isn't, for example. I could obscure the code for the end user, I suppose, but doing so seems contrary to open source philosophy, and probably just presents a challenge. OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. On Jan 30, 2:22 pm, Raffi Krikorian ra...@twitter.com wrote: what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them tohttp://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On 01/30/2010 02:43 PM, Isaiah Carew wrote: So, in simple language: Twitter's policy is that *every user* of *every open source client* register as a *new twitter application*? Or, have I misinterpreted something? And if so, could you explain further what mean? If that were the case, then it would be the requirement for all desktop apps. Open source just makes it easier to grab the key; if you stick your keys in your Air or .NET app, they can still be grabbed. Basically, if you're doing a desktop app (of any kind) with OAuth, there is a risk that your consumer key will be misappropriated. The OAuth spec explicitly acknowledges this, stating that the consumer key/secret is cannot necessarily be trusted to securely identify the consumer. - Michael -- mouse, n: A device for pointing at the xterm in which you want to type. Confused by the strange files? I cryptographically sign my messages. For more information see http://www.elehack.net/resources/gpg. signature.asc Description: OpenPGP digital signature
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. I like those ideas. They match up maintaining a consistent application identity with better key security. The first one seems more workable. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I couldn't care less about apathy. -
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
this is an interesting idea -- what twitter could do is keep key hierarchies mapping a master consumer key to subsidiary consumer keys...? On Sun, Jan 31, 2010 at 8:04 AM, Josh Roesslein jroessl...@gmail.comwrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Yeah basically twitter can allow developers to generate children keys from their master key they received during application registration. The developer is then free to delegate the generated children to whom ever they wish. This gives us freedom to then pick who can sign requests using our application name. We can be very open with this (basically a hidden, public API for the desktop applications) or restrictive (password/secret guarded API) on our end. Josh On Sun, Jan 31, 2010 at 10:45 AM, Raffi Krikorian ra...@twitter.com wrote: this is an interesting idea -- what twitter could do is keep key hierarchies mapping a master consumer key to subsidiary consumer keys...? On Sun, Jan 31, 2010 at 8:04 AM, Josh Roesslein jroessl...@gmail.com wrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I 100% agree. But another idea just struck me, why not put the OAuth part of your app in a DLL (at lest the authentication and communication with twitter part) and hard code it their. You lose some of the open source nature of the app but it will be secure. Sent using BlackBerry® from Orange -Original Message- From: Cameron Kaiser spec...@floodgap.com Date: Sat, 30 Jan 2010 23:02:18 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. +1 -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I'd love to go out with you, but I'm in perpetual denial.
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
But another idea just struck me, why not put the OAuth part of your app in a DLL (at lest the authentication and communication with twitter part) and hard code it their. If you include the key, sooner or later it will be found. Just ask Jon Lech Johansen. It may not be worth it for apps with small user bases, but that's not much security. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- In Computer Science, we stand on each other's feet. -- Brian Reid --
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
That's not all that secure, eventually it will be loaded into memory and can be found by any hacker with some patience. As soon as you distribute any sort of data it is no longer private. You're average Joe might not be able to find it, but any skilled hacker will. And after all the average Joe does not care anyways about OAuth tokens (what's oauth?), but hackers do. So you're kind of blocking the wrong person, it's the hacker you want to stop. Josh On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote: I 100% agree. But another idea just struck me, why not put the OAuth part of your app in a DLL (at lest the authentication and communication with twitter part) and hard code it their. You lose some of the open source nature of the app but it will be secure. Sent using BlackBerry® from Orange -Original Message- From: Cameron Kaiser spec...@floodgap.com Date: Sat, 30 Jan 2010 23:02:18 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. +1 -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I'd love to go out with you, but I'm in perpetual denial.
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Interesting.This is more or less similar to each user registering their own app. But twitter may have better control with this hierarchy. Just wondering if twitter could actually replace 'PIN' part with those key/secret pair i.e when the user clicks 'Download app' link in apps webpage it will do all the initial oauth stuff i.e generating req tokens etc and redirect the user to twitter (https) and (authenticate if required) twitter will generate the new key/secret pair and it will either 1) redirect these values back to the apps download page so that app can embed these values in the download pkg and push this pkg to user or 2) just display those key/secret in twitter page and ask user to manually enter those details after they download the pkg The advantage with the second approach is that the apps providers don't have to implement anything significant other than using the regular oauth stuff (just change the url). Even with the first approach there is no need for any sort of client communication from desktop app to app provider after a pkg is downloaded. Again this whole scenario is for 'PIN' based desktop flows only(not for browser less systems). Basically the reasoning is that if the users have no issues in entering the PIN then they shouldn't have any issues with entering these key/secret pair either. If UX is an issue then the first approach may be used. Any comments on this? On Sun, Jan 31, 2010 at 9:34 PM, Josh Roesslein jroessl...@gmail.comwrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On Sun, Jan 31, 2010 at 08:04, Josh Roesslein jroessl...@gmail.com wrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. How is it better or more secure to have crackers misappropriated your sub key to mimic your application instead of your primary key? They are still pretending to be your application and users won't know any different. If each sub key had its own listing on https://twitter.com/account/connectionsthen there would be some differentiation but then if users install an application five times it would be listed five times. Abraham -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Just to add more . There will always be only one level of sub keys in the hierarchy. Everytime the user downloads the same app the same key pair will be given (like access token/secrets) (a user authentication may be made mandatory in this case) On Mon, Feb 1, 2010 at 12:39 AM, srikanth reddy srikanth.yara...@gmail.comwrote: Interesting.This is more or less similar to each user registering their own app. But twitter may have better control with this hierarchy. Just wondering if twitter could actually replace 'PIN' part with those key/secret pair i.e when the user clicks 'Download app' link in apps webpage it will do all the initial oauth stuff i.e generating req tokens etc and redirect the user to twitter (https) and (authenticate if required) twitter will generate the new key/secret pair and it will either 1) redirect these values back to the apps download page so that app can embed these values in the download pkg and push this pkg to user or 2) just display those key/secret in twitter page and ask user to manually enter those details after they download the pkg The advantage with the second approach is that the apps providers don't have to implement anything significant other than using the regular oauth stuff (just change the url). Even with the first approach there is no need for any sort of client communication from desktop app to app provider after a pkg is downloaded. Again this whole scenario is for 'PIN' based desktop flows only(not for browser less systems). Basically the reasoning is that if the users have no issues in entering the PIN then they shouldn't have any issues with entering these key/secret pair either. If UX is an issue then the first approach may be used. Any comments on this? On Sun, Jan 31, 2010 at 9:34 PM, Josh Roesslein jroessl...@gmail.comwrote: I wonder if Twitter could provide developers with an URL for dynamically generating additional consumer tokens for their applications. When the user installs a new application it will contact the developer's server to download its own consumer key/secret. The developer's server will use its master consumer key/secret to post to the Twitter URL to fetch a new consumer key/secret. The consumer pair will then be sent to the application via a secure channel (HTTPS?) to prevent man in the middle attacks. The application will then use this new consumer pair to perform all signing of requests. Another option is to package the dynamically generated consumer pair in the application download package. Each new download will have its own unique consumer pair ready for use once the user has downloaded the application. This still requires the developer maintain a server to perform the consumer pair generation, but it does keep the master pair secure and each application gets its own pair. But applications that are willing to make this trade off can keep the UX good, control what application instances can authorize on the application's behalf, and the master pair is never shared. You can always still distribute the master pair with each application if these security gains are not that important to you. Or you can require your users to generate their own consumer pair if UX is not much of an issue (example: distributed server applications) where an advance users is at the wheel and won't have issues figuring this out. Josh
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I would like to point out the official Flickr Uploadr application that is OAuth and open source. If you download it as a user [1] it includes their official API keys but if you download it as a developer [2] you implement your own API keys. Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/ Abraham [1] http://www.flickr.com/tools/uploadr/ [2] http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76 On Sun, Jan 31, 2010 at 10:06, Josh Roesslein jroessl...@gmail.com wrote: That's not all that secure, eventually it will be loaded into memory and can be found by any hacker with some patience. As soon as you distribute any sort of data it is no longer private. You're average Joe might not be able to find it, but any skilled hacker will. And after all the average Joe does not care anyways about OAuth tokens (what's oauth?), but hackers do. So you're kind of blocking the wrong person, it's the hacker you want to stop. Josh On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote: I 100% agree. But another idea just struck me, why not put the OAuth part of your app in a DLL (at lest the authentication and communication with twitter part) and hard code it their. You lose some of the open source nature of the app but it will be secure. Sent using BlackBerry® from Orange -Original Message- From: Cameron Kaiser spec...@floodgap.com Date: Sat, 30 Jan 2010 23:02:18 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. +1 -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I'd love to go out with you, but I'm in perpetual denial. -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Hmmm. Flickr is a service provider but if a consumer(developer) like Tweetdeck were to implement oauth and if they distribute keys there is always this problem of misusing those and the very first thing twitter would do is ban that application. Flickr can share it, but developers? i do not know . On Mon, Feb 1, 2010 at 12:49 AM, Abraham Williams 4bra...@gmail.com wrote: I would like to point out the official Flickr Uploadr application that is OAuth and open source. If you download it as a user [1] it includes their official API keys but if you download it as a developer [2] you implement your own API keys. Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/ Abraham [1] http://www.flickr.com/tools/uploadr/ [2] http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76 On Sun, Jan 31, 2010 at 10:06, Josh Roesslein jroessl...@gmail.comwrote: That's not all that secure, eventually it will be loaded into memory and can be found by any hacker with some patience. As soon as you distribute any sort of data it is no longer private. You're average Joe might not be able to find it, but any skilled hacker will. And after all the average Joe does not care anyways about OAuth tokens (what's oauth?), but hackers do. So you're kind of blocking the wrong person, it's the hacker you want to stop. Josh On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote: I 100% agree. But another idea just struck me, why not put the OAuth part of your app in a DLL (at lest the authentication and communication with twitter part) and hard code it their. You lose some of the open source nature of the app but it will be secure. Sent using BlackBerry® from Orange -Original Message- From: Cameron Kaiser spec...@floodgap.com Date: Sat, 30 Jan 2010 23:02:18 To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. +1 -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I'd love to go out with you, but I'm in perpetual denial. -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
How is it better or more secure to have crackers misappropriated your sub key to mimic your application instead of your primary key? They are still pretending to be your application and users won't know any different. If each sub key had its own listing on https://twitter.com/account/connections then there would be some differentiation but then if users install an application five times it would be listed five times. Abraham I am not entirely sure what security benefits there is for having unique consumer pairs per an application instance. One I can think of is during the get access token step w/o HTTPS. A man in the middle could in theory steal the access token and generate valid signatures if the consumer secret is publicly known. If each instance had its own consumer pair then the attacker could do nothing with this access token. There may be other benefits of having a strong consumer secret for the signing process. A person more familiar with crypto would have to weigh in on that issue. For the connections listing it would probably only be listed once per an application. All access tokens generated from the sub-keys of the master consumer key would be invalidated. This may cause issues if the comprimised account was caused by using a stolen consumer sub-key. Both good and bad access tokens would get killed. Best thing is to make your application resilient and just have the user repeat the OAuth dance if the access tokens you have ever gets invalidated. Having multiple consumer keys also allows providing both a server and desktop service using the same application name. You don't want to be running the same consumer key you have publicly shared. Here your server and desktop applications would each get their own consumer pair. There is nothing you can really do to block impersonation of applications. If you grant code that is running on a machine you don't have control over access to a consumer pair linked to your application, it can do what ever it wants. You can play hide and seek the best you can with the hackers, but its a never ending battle of changing consumer pairs after they get leaked over and over again. I think the big question is how big of a deal is impersonating the from attribute? People are going to associate the content of the tweet with the account it was posted with, not the application that delivered it. If its a spam message from freecomputers3332 account posted by Tweetapp, people are not going to say hey that Tweetapp is spamming me. Instead they are going to report freecomputer3332 as spam and forget it.
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Ironically all of these massive threads talking about impersonating applications is probably just making more crackers aware that they can do this. :-/ You're right! Openness about security is really going to hurt us all! Everyone, quick, sh! The bad guys are stupid and will never figure it out if we just keep quiet! OK, sorry, I couldn't resist the bait. ;-) Especially coming from someone that I know appreciates openness. No, I don't actually feel that way. I do actually see your point, but I think the value of discussing threats, so long as the discussions remain unspecific, are probably more valuable than they are detrimental. Also, I think you have it right, that distribution of the source sans keys and the binary with keys is the way to go. I completely agree that it's the obvious practical solution. It's the one that took myself for my OSS OAuth code. However, it also misses the point. The point is that the keys not kept safe in any desktop app, and the challenges are double in open source apps. Up until this point they've probably been safe enough because there have been few targets worth the effort of cracking. I suspect that will change when the clients with many users enter the picture. With many more users there are many more reasons why someone might want to spoof as a specific client. I'd say its a pretty reasonable bet that one of the major desktop clients will be compromised within a year or so of implementing OAuth -- and will probably result in a lot of user frustration. It seems like their will be ample motivation and little to prevent them. Only time will tell, you're free to come and laugh at me if it doesn't happen. Bookmark this email, we'll check back in 18 months. ;-) Isaiah
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On Sun, Jan 31, 2010 at 1:36 PM, Isaiah Carew isa...@me.com wrote: Also, I think you have it right, that distribution of the source sans keys and the binary with keys is the way to go. I completely agree that it's the obvious practical solution. It's the one that took myself for my OSS OAuth code. I'm not convinced that distributing *any* oAuth capability to end users, even in binary form - even in a form where said binary interfaces in secure ways with the underlying desktop / mobile ways to persist the consumer key and secret - is the way to go. I personally think the way to go is to deploy applications as servers with the thinnest possible client imaginable. If ChromeOS netbooks actually existed today, that's what I'd be building - servers that interacted with Twitter on behalf of users with ChromeOS netbooks. Given what I know now about oAuth, I'm not planning on releasing any oAuth desktop applications. I never *was* planning mobile ones - the kind of processing I have in mind flat out can't be done on a mobile, so I'd have to have a server anyway to deploy to mobile users. I'd say its a pretty reasonable bet that one of the major desktop clients will be compromised within a year or so of implementing OAuth -- and will probably result in a lot of user frustration. It seems like their will be ample motivation and little to prevent them. Only time will tell, you're free to come and laugh at me if it doesn't happen. Bookmark this email, we'll check back in 18 months. ;-) Isaiah Well ... the motivation is there now, with or without oAuth. And oAuth doesn't make it *easier* to compromise a desktop application. As far as desktop user frustration is concerned, though, there are so many other sources of desktop user frustration already - botnets, weekly virus scans that take hours, browser vulnerabilities, 15-30 minute waits before the machine is open for business, and, of course, the hundreds of dollars one pays per year for just a license to use the desktop software - that I think a compromised Twitter desktop platform isn't going to get much attention unless it does something really nasty, like a DDOS against Twitter. -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On Sun, Jan 31, 2010 at 5:30 PM, funkatron funkat...@gmail.com wrote: ... maybe helping Twitter's engineering team understand the problems better, should be top priority. I think Twitter's engineering team does understand the issues. But I think the primary responsibility lies with us developers, and I for one don't see the point in investing effort building desktop Twitter applications, given a. They're tough to scale down to mobile platforms, and mobile usage seems to be where the growth and action are in social media, and b. oAuth or not, desktop applications are difficult to secure. c. The Streaming API isn't designed to play well with desktops / laptops / mobiles. I agree that much of this seems like beating a dead horse, but I'd also like to see more official response about it, even if it's just hey, we know, and this is just the tradeoff we need to make. Otherwise, I think we're providing feedback as requested on the API in general, and authentication in particular. The environment in which Twitter and the Twitter development community operate is changing rapidly. The *desktop* oAuth tradeoffs may have made sense a year ago. before the huge growth spurt in awareness and usage of Twitter in 2009. As I've noted, I think the *server* oAuth tradeoffs still make sense. I think we need to take the advice of Wayne Gretzky and skate to where the puck is going to be. I should also note that I have never used a desktop Twitter client. I installed one once on my Linux workstation, and got frustrated by the Adobe AIR platform issues. The client wasn't giving me any functionality I couldn't get from a free server like HootSuite or even from Firefox, and there wasn't anything else I wanted that used AIR. So I'm not losing anything if desktop oAuth doesn't get enhanced. -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
On Sun, Jan 31, 2010 at 8:26 PM, Cameron Kaiser spec...@floodgap.com wrote: I think Twitter's engineering team does understand the issues. But I think the primary responsibility lies with us developers, and I for one don't see the point in investing effort building desktop Twitter applications, given a. They're tough to scale down to mobile platforms, and mobile usage seems to be where the growth and action are in social media, and b. oAuth or not, desktop applications are difficult to secure. c. The Streaming API isn't designed to play well with desktops / laptops / mobiles. So don't develop one. But, speaking as a dev who eats his own dog food, I prefer to have a console open running TTYtter than mashing refresh all the time in Camino. Desktop apps are a useful part of the ecosystem, and I wouldn't be participating in Twitter anywhere near as much as a user if I had a much higher barrier to do so or had to trust a third-party service and add another layer on to do so on my behalf. I assume @funkatron's users have the same opinion. Yes, I write my own desktop apps too, but I don't distribute them. I never saw the need to use a desktop client when the browser worked just fine. Then again, I don't own a Mac and don't use Windows very often. Maybe a desktop client on a Windows or Mac makes more sense than it does on Linux. Assuming, of course, that a Linux desktop itself makes any sense - there aren't a lot of folks who agree with me on my choice of desktop. ;-) -- M. Edward (Ed) Borasky http://borasky-research.net I've always regarded nature as the clothing of God. ~Alan Hovhaness
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I assume you have 2 versions: 1) the opensource code that developers can use and modify. You would not include your consumer key/secret and have instructions on how to get their own. Although you could include your consumer values as defaults and get free publicity from any projects that don't create and use their own. 2) the compiled version that end users will download and expect to just work. In these include your consumer key/secret but be aware that use them for limited nefarious purposes. Applications could take your consumer information and if they convince users to go through the authentication process make requests to the API that appear to be from your application. Abraham On Sat, Jan 30, 2010 at 11:22, Raffi Krikorian ra...@twitter.com wrote: what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- Abraham Williams | Community Advocate | http://abrah.am Project | Out Loud | http://outloud.labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. Sent from Seattle, WA, United States
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
I suppose the only other way to make the UX good and to keep the consumer secret absolutely hidden is to proxy all requests through a hosted server. This does come as a cost of having to pay for a server to perform the proxy work. But it's really the only option at the moment I can think of that's 100% safe. Josh On Sat, Jan 30, 2010 at 6:35 PM, funkatron funkat...@gmail.com wrote: Not to be a complete pill, but that is a terrible, terrible initial experience for the average desktop app user. There is no way I would or could reasonably ask one of my users to register an app themselves, then fill in obscure hashes. The OAuth secret is simply impossible to use securely with open source, end-user-oriented applications. My only option with Spaz, when Twitter decides to take away basic auth, is to pray someone doesn't decide to steal my secret hash. Compiling does make getting the key more difficult, but assuming that desktop apps are compiled isn't a good idea -- Spaz isn't, for example. I could obscure the code for the end user, I suppose, but doing so seems contrary to open source philosophy, and probably just presents a challenge. OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. On Jan 30, 2:22 pm, Raffi Krikorian ra...@twitter.com wrote: what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them tohttp://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. +1 -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I'd love to go out with you, but I'm in perpetual denial.
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Why not check for the presence of the keys on start-up, if they are missing re-direct the user (open a browser window) to the new apps page and/or a step-by-step guide on you site. then store the keys as normal Sent using BlackBerry® from Orange -Original Message- From: Raffi Krikorian ra...@twitter.com Date: Sat, 30 Jan 2010 11:22:13 To: twitter-development-talktwitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
So, in simple language: Twitter's policy is that every user of every open source client register as a new twitter application? Or, have I misinterpreted something? And if so, could you explain further what mean? Thanks, Isaiah what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. isaiah http://twitter.com/isaiah On Jan 30, 2010, at 11:22 AM, Raffi Krikorian wrote: what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them to http://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
