Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On 9/1/2010 7:47 PM, Julio Biason wrote: OAuth certainly makes sense as a model for "never type your password in some weird site 'cause you don't know when they say that they couldn't connect to Twitter is really that or they are just storing your login and password to abuse the ecosystem". The whole problem with it is the revocation of keys when it's believed that the app is not behaving properly because one single point abuses it. In that case, the point should be blocked, not the application itself. Now on that point I can agree, and the revocation model should give application designers the chance to prove that they deserve the benefit of the doubt. How you do that while letting Twitter run a secure system is the problem. In terms of Open Source applications perhaps some sort of "verification" process for applications to submit their source code (not an approval process per se). Verified apps would be given the benefit of the doubt and the individual users would be shut down (or at least the authentications for those individual users). -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On 9/1/2010 7:01 PM, Julio Biason wrote: On Wed, Sep 1, 2010 at 9:56 PM, John Meyer wrote: And rendering the key useless to the spammer. And to you. And your users. That's the whole problem with it. Yes, one could simply strings(1) one Mac app and probably retrieve the keys and spam the hell of Twitter with it. For the spammer, it doesn't matter if the key is revoked as he could just get another one; the real problem appears to legit users that follow all the guildelines and really contribute for the system. The fact that open source apps, distributing their keys, make them "easy targets" for valid keys but that doesn't mean that applications that "protect" their keys are safer. For the developer, safer can be argued. But I don't think you can argue the fact that for the end user a limited key that only lets an application post and read and can be revoked even if the application goes rogue isn't safer than one (ie the password) that lets them log into that users account and change the password. That's what I think twitter is saying when they say oAuth is safer. It is safer for the end user. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Wed, Sep 1, 2010 at 10:20 PM, John Meyer wrote: > 1. reverse engineering a consumer key combo from a legit program, creating > user accounts and generating tokens, spamming it until it's locked out, > tracking down another legit program, reverse engineering it, lathering, > rinsing, and repeating > > vs. > > 2. generating his own consumer keys through twitter and using those. > > > the spammer's going to take #1. ... unless he manages to get hold of an app like Tweetie or even Twitter for iPhone, which are hugely used around. I really doubt Twitter would revoke those applications secret and let a huge number of users in the dark. > Somehow, I would think that #2 would be a > whole lot easier. Besides, whether or not you think it's safer I seriously > doubt that Twitter is thinking that oAuth is the only security measure. Personally, I believe that security through obscurity is no security at all. But let's assume that OAuth is more secure (or, at least, harder to be "cracked"). My problem with this all is that: 1) If I want to offer the same "hard to crack" level of closed source apps (since they require a tool different than grep), I'd have to force my users (desktop users, remember) to register their own apps. 2) If I want to offer an easier UX, I'd have to provide my own key and, thus, offer a lower security than other apps. OAuth certainly makes sense as a model for "never type your password in some weird site 'cause you don't know when they say that they couldn't connect to Twitter is really that or they are just storing your login and password to abuse the ecosystem". The whole problem with it is the revocation of keys when it's believed that the app is not behaving properly because one single point abuses it. In that case, the point should be blocked, not the application itself. -- Julio Biason Twitter: http://twitter.com/juliobiason -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On 9/1/2010 7:01 PM, Julio Biason wrote: That's the whole problem with it. Yes, one could simply strings(1) one Mac app and probably retrieve the keys and spam the hell of Twitter with it. For the spammer, it doesn't matter if the key is revoked as he could just get another one; the real problem appears to legit users that follow all the guildelines and really contribute for the system. So for the spammer in the choice between: 1. reverse engineering a consumer key combo from a legit program, creating user accounts and generating tokens, spamming it until it's locked out, tracking down another legit program, reverse engineering it, lathering, rinsing, and repeating vs. 2. generating his own consumer keys through twitter and using those. the spammer's going to take #1. Somehow, I would think that #2 would be a whole lot easier. Besides, whether or not you think it's safer I seriously doubt that Twitter is thinking that oAuth is the only security measure. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Wed, Sep 1, 2010 at 9:57 PM, John Meyer wrote: > That's the way Twitter Tools for Wordpress works, and it isn't ackward at > all. It's description leaves something to be desired, but it ain't rocket > science. WordPress users are "a complete different beast" than desktop users. Even if you use some easy install process like Dreamhost "One Click Install", you still need to know where your WordPress install is, unpack and install in the proper directory. Most desktop users don't want that hassle; the application that "works" is the one that they click the icon and it just works. Or one that they can just keep pressing next, next, next, ok. If you ask them to register their apps with the proper configurations on Twitter site (and, as far as I remember, the registration page defaults to browser apps and not desktop apps), they will believe your app is "too hard to use" and will take one that doesn't ask them so many things, even if their real security is not even slightly better. -- Julio Biason Twitter: http://twitter.com/juliobiason -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Wed, Sep 1, 2010 at 9:56 PM, John Meyer wrote: > And rendering the key useless to the spammer. And to you. And your users. That's the whole problem with it. Yes, one could simply strings(1) one Mac app and probably retrieve the keys and spam the hell of Twitter with it. For the spammer, it doesn't matter if the key is revoked as he could just get another one; the real problem appears to legit users that follow all the guildelines and really contribute for the system. The fact that open source apps, distributing their keys, make them "easy targets" for valid keys but that doesn't mean that applications that "protect" their keys are safer. -- Julio Biason Twitter: http://twitter.com/juliobiason -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On 9/1/2010 6:46 PM, Julio Biason wrote: On Wed, Sep 1, 2010 at 7:58 PM, John Meyer wrote: And that assumes that you distribute the consumerkey and consumersecret with the app. Nothing about Open Source requires this. You could just as easily just distribute the source and require that users obtain their own ConsumerKey combos. The problem, in this case, is the awkward UX. "Hello user! Thanks for downloading application X! To use it, you must register your application on Twitter, then authorize it to be used! And don't forget to use the proper options or it won't work, ok?" That's the way Twitter Tools for Wordpress works, and it isn't ackward at all. It's description leaves something to be desired, but it ain't rocket science. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On 9/1/2010 6:03 PM, Mike Desjardins wrote: Yes, and your application's consumer secret ends with the following characters: jOU I obviously know the entire string and have the good sense not to reveal it here. The point is, it's trivially easy for me or anybody else to unzip your "packaged download" and get your secret. You didn't need to send it to me. I can now start spoofing your chrome extension in my Twitter client. I can use your secret to spam the crap out of people, and the folks at Twitter will eventually revoke the key, rendering your chrome extension useless to your users. And rendering the key useless to the spammer. Besides, if I'm a spammer what makes more sense to me: hijacking consumer key combos one by one and spamming them to the point of cancellation or developing a way to get hundreds of my own keys to do the spamming (again, ignoring the fact that you need user tokens to spam along with those "stolen" consumer key combos). That is unless you assume that spammers are doing it just to screw with programmers and not to make a profit. Is oAuth absolutely safe? No, of course not. No computer, outside of the one locked in a building with no internet connections, outside power sources, or walls, is safe. But oAuth is definitely safer at least from the point of view of the user who only has to worry about shutting off a single app as opposed to changing their password. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Wed, Sep 1, 2010 at 7:58 PM, John Meyer wrote: > And that assumes that you distribute the consumerkey and consumersecret with > the app. Nothing about Open Source requires this. You could just as easily > just distribute the source and require that users obtain their own > ConsumerKey combos. The problem, in this case, is the awkward UX. "Hello user! Thanks for downloading application X! To use it, you must register your application on Twitter, then authorize it to be used! And don't forget to use the proper options or it won't work, ok?" "Oh wait I sec... Why I need to register and _then_ authorize it? It doesn't make sense! That other application don't ask me all this shit..." -- Julio Biason Twitter: http://twitter.com/juliobiason -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
I have an open source Twitter client for Google Chrome and this is how I distribute it. The source is available with no API key. If developers wish to play with the source they must register their own OAuth application. http://github.com/abraham/omnitweet For users there is a packaged download that includes an API key. They just install the extension and off they go. http://github.com/abraham/omnitweet/downloads Abraham - Abraham Williams | Hacker Advocate | http://abrah.am @abraham | http://projects.abrah.am | http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private. On Wed, Sep 1, 2010 at 15:58, John Meyer wrote: > On 8/19/2010 11:50 AM, briandunnington wrote: > >> as Julio stated above, the official response from Taylor (in another >> thread) was that this solution will *not* be rolled out. there is >> currently no other alternative being offered other. >> >> and just to repeat what has already been said a few time in this >> thread - this is not just a problem with open source apps. any app >> that is distributed (ie: not running on your own web server) has this >> problem. i read on Daring Fireball the other day about a new Twitter >> app called Hibari, so i downloaded it and got the consumer key and >> secret within a couple of minutes. others apps are just as susceptible >> - any time the user has the code, the secret must be considered >> unsecure. >> >> > > And that assumes that you distribute the consumerkey and consumersecret > with the app. Nothing about Open Source requires this. You could just as > easily just distribute the source and require that users obtain their own > ConsumerKey combos. > > > -- > Twitter developer documentation and resources: http://dev.twitter.com/doc > API updates via Twitter: http://twitter.com/twitterapi > Issues/Enhancements Tracker: > http://code.google.com/p/twitter-api/issues/list > Change your membership to this group: > http://groups.google.com/group/twitter-development-talk?hl=en > -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On 8/19/2010 11:50 AM, briandunnington wrote: as Julio stated above, the official response from Taylor (in another thread) was that this solution will *not* be rolled out. there is currently no other alternative being offered other. and just to repeat what has already been said a few time in this thread - this is not just a problem with open source apps. any app that is distributed (ie: not running on your own web server) has this problem. i read on Daring Fireball the other day about a new Twitter app called Hibari, so i downloaded it and got the consumer key and secret within a couple of minutes. others apps are just as susceptible - any time the user has the code, the secret must be considered unsecure. And that assumes that you distribute the consumerkey and consumersecret with the app. Nothing about Open Source requires this. You could just as easily just distribute the source and require that users obtain their own ConsumerKey combos. -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Mon, Aug 9, 2010 at 1:50 PM, Meepnix wrote: > Has this solution for Open Source applications using OAuth with the > Twitter API been implemented yet? As the deadline for Basic > authentication removal is looming very close; 16th August, end of this > week. On another thread, Taylor said "No". So, basically, you will have to let your secret "leak" so your users can use your app. -- Julio Biason Twitter: http://twitter.com/juliobiason
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
The answer is soon! :) We hope to roll this out more widely this week. On Mon, Jun 28, 2010 at 7:56 AM, Decklin Foster wrote: > Taylor Singletary wrote: > > We're waiting on a few minor bug fixes to be in place before rolling this > > out to a wider audience. I'll post a new message when things are good to > go > > and we're ready to accept applications into the feature. > > Any update or ETA on this? I have an app that I'm eager to test out. > (I notice that if you open http://dev.twitter.com/apps/key_exchange > with a valid oauth_consumer_key, instead of a 404 there is a page that > says "Sorry, key exchange is not permitted for this application." Does > this mean the answer is "soon"?) > > -- > things change. > deck...@red-bean.com >
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Hi Everyone, We're waiting on a few minor bug fixes to be in place before rolling this out to a wider audience. I'll post a new message when things are good to go and we're ready to accept applications into the feature. Taylor On Sun, Jun 20, 2010 at 1:30 AM, nov wrote: > Hi, Twitter API team > > Is this feature already released? > If so, how can we register key_exchange enabled consumers? > > On 6月12日, 午前7:56, Taylor Singletary > wrote: > > Hi Developers, > > > > As has been discussed on the list recently, OAuth and Open Source > > applications are a difficult combination because token secrets shouldn't > be > > embedded in widely distributed code. > > > > We're pleased to announce that we've devised a solution to this problem. > > > > Next week, we plan to release a new extension to the Twitter API that > will > > allow Open Source applications to obtain OAuth consumer keys and secrets > for > > their users, without having to distribute an application secret. > > > > Approved Open Source client applications will have an easy to implement > > ability, through dev.twitter.com, to generate new client tokens & > secrets to > > be used specifically for each new instance of the application. > > > > While completing the process does require the end-user to complete a few > > extra operations, we think this is a good compromise. > > > > The source tag on tweets published by the child applications generated > with > > this approach will be a variation on the originating application's name. > For > > examples, if the name of the parent application was "AdventureTweet" and > the > > user's screen name was @zork, then the child application's name would be > > "AdventureTweet (zork)". > > > > The work flow for these applications will be something like this: > > > > 1. You store your API Consumer Key in your application distribution > (but > > never your secret!). > > 2. A user downloads/installs/checks out your open source application > and > > runs it for the first time > > 3. Your application builds a URL to our key exchange endpoint, using > your > > consumer key. > > Example: > http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi... > > 4. You send the user to that URL in whatever way makes sense in your > > environment. > > 5. That user will have to login using their Twitter credentials (if > they > > aren't already), and then approve your application's request to replicate > > itself on the user's behalf. > > 6. The approval will require that the user agrees to our terms of > service, > > as this process results in them having control of their own application > > 7. The user is presented with a string that they are asked to paste > into > > your application. The string will contain ah API key and secret, in > addition > > to an access token and token secret for the member: everything that's > needed > > to get the user up and running in your application. > > 8. The user pastes the string into your application, which then > consumes > > and stores it to begin performing API calls using OAuth. > > > > The string containing the keys will be x-www-form-urlencoded. To keep the > > string brief, it will contain abbreviated key names. > > > > An example: > > > ck=KIyzzZUM7KvKYOpnst2aOw&cs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3E&at=5 > 42212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeA&ats=FFdeOEwxOBWPPREd55 > dKx7AAaI8NfpK7xnibv4Yls > > > > Where: "ck" - consumer key, "cs" - consumer secret, "at" - access token, > > "ats" - access token secret > > > > This kind of key requisition service is new to the Twitter ecosystem, and > > we're going to be closely monitoring it for abuse. Once we announce its > > availability, we'll begin taking requests for Open Source applications > that > > would like to offer the feature in their application. > > > > We're excited to offer this solution to the open source community. Thanks > > everyone! > > > > Taylor Singletary > > Developer Advocate, Twitterhttp://twitter.com/episod >
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Interesting details, and see below: On Mon, 14 Jun 2010 10:51:34 -0700 Zac Bowling wrote: > In facebook's desktop authflow, rather then giving you an > ... > Basically when it comes to desktop apps, Facebook can't for sure tell > the difference between my desktop app and illegitimate one. Not only that, they (or anyone) cannot tell a legitimate desktop from an illegitimate one. An illegitimate person can take a desktop with a bunch of legitimate apps and do illegitimate things with the whole collection. And then we should not forget that a mobile phone is a the same as a desktop, from the point of view of the web server. Phones are usually not protected very well, both in terms of autheticating users and in physical terms. What is it that makes an app illegitimate? Basically that is impersonates the user, and does things the user doesn't want done. Unless of course the app does business on behalf of a third party with both the user and the server (twitter, facebook, ...). Collecting data is "doing business" in this sense. Then the app is an agent for that third party. But for a lot of apps, this is not the case, they act entirely as an agent for the user. They are no different than browsers in this respect. -- Bernd Stramm
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
In facebook's desktop authflow, rather then giving you an access_token endpoint to call with a secret to exchange a callback and get an valid access_token, you instead call authorize and it will redirect the user to a login_success.html page on facebook.com with the access token in a fragment on that page. (see http://developers.facebook.com/docs/authentication/desktop ) Their idea is that if you can embed a browser and get the user to authenticate through it, you can inspect the url of the embedded browser and detect when it hits login_success.html and take the access token fragment and store it. However, what is interesting about that is that I can embed client_ids I stole from other desktop apps (and possibly other web apps if they don't protect against it) and generate valid access_tokens against other ids in my own desktop app. The user may notice the app they authorize isn't the one they are using because because facebook identifies the app with its name and icon on the authorize page. However if I'm being evil, i could social engineer the user some how like I could name my app the same as the one I'm stealing or something similar and use the same icon, and then I can get access tokens like I'm that app. Basically when it comes to desktop apps, Facebook can't for sure tell the difference between my desktop app and illegitimate one. If Facebook blocks entire apps or rate limits by them, then I can still DOS the app by using their client_id. It doesn't offer anymore application identity protection then just embedding a secret and using the OAuth 1.0a flow and embedding secrets. Facebook probably realizes this. Since you can mark your app as a desktop app and not a web app in your app settings, they probably realize this issue and know that you can't always trust the desktop clients so why even bother with secrets (probably good that they ask your app type upfront for this reason and it doesn't give a false sense of security by even having a secret). From an operations perspective for FB, it gives them less options to safely blacklisting desktop apps without taking out legitimate ones though. Zac Bowling @zbowling On Jun 14, 2010, at 10:00 AM, Jef Poskanzer wrote: > Yeah, what Ryan said. > > Also, > > On Jun 13, 1:40 pm, segphault wrote: >> Facebook and Google Buzz both offer desktop-appropriate OAuth >> authentication flows which do not require a consumer secret key and do >> not require the user to go through a complicated copy/paste process. > > I'm curious what they are doing. Do they give up on identifying the > application and just identify the user?
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Right, and... On Sat, 12 Jun 2010 16:09:47 -0700 (PDT) Jef Poskanzer wrote: > You know, it's right there in the OAuth RFC. > > http://tools.ietf.org/html/rfc5849#section-4.6 > > 4.6. Secrecy of the Client Credentials > >In many cases, the client application will be under the control of >potentially untrusted parties. For example, if the client is a >desktop application with freely available source code or an >executable binary, an attacker may be able to download a copy for >analysis. In such cases, attackers will be able to recover the >client credentials. > >Accordingly, servers should not use the client credentials alone to >verify the identity of the client. But for a desktop/mobile standalone application, there is no single client entity. What is called the "consumer" is not an entity. It is a program running on a device, not a company. And to re-quote them: > For example, if the client is a >desktop application with freely available source code or an >executable binary, an attacker may be able to download a copy for >analysis. This borders on being silly - why bother with analysis, when the attacker can just run the program. The oauth system comes from client/server concepts and client/server thinking. In that scenario, the authentication is between one client and two servers. That is not the case with most desktop/mobile apps. -- Bernd Stramm
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Quoting funkatron : Yeah, it's really the step of manually getting that long string of seemingly-random characters from one app to another. a callback url makes sense for web-based apps. Something like PIN auth that would allow a desktop/mobile app to make an HTTP call and recover the string programatically would be good, I think. Typing 4-6 characters is much, much easier than copying and pasting that long string. Yes! Can we get a PIN workflow for end users? That would be perfect! That's what I'm using now.
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Jun 12, 2010, at 3:05 PM, Bernd Stramm wrote: >> I've been pondering how you could solve this from my experience with >> solving these issues with SSL/TLS. One idea is having a sort of >> delegation chain where I could generate a new delegated secret for >> each copy of my app I distribute rather then using my same static >> secret directly in all my apps and then the client could pass the >> authentication chain up when it goes to Twitter to get an access >> token. > > The question is also - why do you care which copy of your app it is? > People using your app will post silly things, engage in slander of > other people, commit crimes, plot revolutions. Yes, the reason I'm worried is when a token/secret is blocked/revoked, it doesn't take down all clients using that same key in my app. Currently I get one consumer token/secret so if twitter needs to block one bad user running around using the key they reverse engineered from my compiled/obfuscated app, it may take down all my users if they block the entire token/secret (hopefully twitter investigates and warns me and blocks the offending IPs rather then the entire token/secret to give me some time to rev a new key and figure out a deployment but that is asking a lot from them). Having the ability to issue multiple consumer token/secrets per app, or having delegated chaining (like in SSL), I have some ability to mitigate the issue a bunch and give twitter the ability to block a much smaller subset of my users if a key was extracted and used abusively. OAuth 1.0a isn't well designed for desktop/mobile apps and it's more than just usability issues that the Twitter gang are trying tackle with things like xAuth. It wasn't designed with the thought that keys could be compromised by third parties embedded inside apps. I can only hope it's fixed OAuth 2.0. Just ideas. :-) Zac Bowling @zbowling
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Sat, 12 Jun 2010 13:25:44 -0700 Zac Bowling wrote: > On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote: > > Application authors are being asked to devote substantial resources > > to the OAuth conversion, but OAuth provides no security for > > application authors! > > It does from a web app perspective which is the primary design goal > of OAuth since there would be no distribution of your secret in that > scenario. Precisely. OAuth is designed for a 3-party security deal: Twitter running on some host, the App running on another host, and the User running on a third. OAuth is pretty useless for a 2-party situation, as is present in a desktop/mobile app on the users device. This isn't all that surprising, since it is designed for something different. > ... shipped are at risk then. Your only recourse is to rev your secret > and force all your users to upgrade their apps to get new keys. Another recourse might be to design a security approach for the app-on-user-device scenario, rather than trying to shoehorn a 3-party scheme into this. > .. this isn't that bad since twitter isn't hosting credit card > data or anything of major risk and you basically devolve into the > same issue we had with app identify we had with basic auth and > passing clear text source ids (except that maybe now all your apps > are crippled). Right. As long as the app doesn't do any side business with a third party. If it does, then it should not use twitter's authentication for that purpose. > I've been pondering how you could solve this from my experience with > solving these issues with SSL/TLS. One idea is having a sort of > delegation chain where I could generate a new delegated secret for > each copy of my app I distribute rather then using my same static > secret directly in all my apps and then the client could pass the > authentication chain up when it goes to Twitter to get an access > token. The question is also - why do you care which copy of your app it is? People using your app will post silly things, engage in slander of other people, commit crimes, plot revolutions. Are you responsible for these things? Is Twitter responsible for broadcasting the content? While we're at it, let's go after the phone manucacturer, the network bandwidth provider. > ... > Right now though, one solution if you are ultra paranoid if you are > going to distribute software, is to proxy the calls from your own > software through your own web service (which would render the ease of > use you get from xAuth moot but you are sacrificing usability for > security). You mean something like Microsoft authorization codes. Or make them download a UUID with the code, and send that code to twitter for each individual downloaded copy. Of course once the download count goes into the millions, twitter will love to store all those IDs. And of course every application developer has a website that handles all the downloads, none of them use google code, sourceforge, github, ... oh wait. Oh well, why bother. -- Bernd Stramm
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
> Yeah, it's really the step of manually getting that long string of > seemingly-random characters from one app to another. a callback url > makes sense for web-based apps. > > Something like PIN auth that would allow a desktop/mobile app to make > an HTTP call and recover the string programatically would be good, I > think. Typing 4-6 characters is much, much easier than copying and > pasting that long string. That sounds good to me too. That could also semi-automate the process. Taylor and Raffi? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- My Pink Floyd code: v1.2a s BO 1/0/pw tinG 0? 0 Relics 2 8 <6mar98>
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote: > Application authors are being asked to devote substantial resources to > the OAuth conversion, but OAuth provides no security for application > authors! It does from a web app perspective which is the primary design goal of OAuth since there would be no distribution of your secret in that scenario. With OAuth, the issue is that if you are distributing secrets out that are embedded in your app, even with all the measures you can take to encrypt and obfuscate them, they can still be extracted at some point if someone has time. The issue is compounded since the app uses the same key universally in all the versions they ship that work so you are screwed if someone does yank your key. All versions you shipped are at risk then. Your only recourse is to rev your secret and force all your users to upgrade their apps to get new keys. In practice, this isn't that bad since twitter isn't hosting credit card data or anything of major risk and you basically devolve into the same issue we had with app identify we had with basic auth and passing clear text source ids (except that maybe now all your apps are crippled). I've been pondering how you could solve this from my experience with solving these issues with SSL/TLS. One idea is having a sort of delegation chain where I could generate a new delegated secret for each copy of my app I distribute rather then using my same static secret directly in all my apps and then the client could pass the authentication chain up when it goes to Twitter to get an access token. This is similar to the idea of having the ability to issue multiple secrets against a single app like I was suggesting earlier which could work with the OAuth spec today. However a delegation system would be even better so I could issue delegated secrets at will without going back to Twitter, although that idea would probably require extending the OAuth spec to handle passing signed delegation chains of some kind. I'm hoping OAuth 2\WRAP allows this somehow since it builds on SSL/TLS instead of reinventing the wheel. There is a lot OAuth could learn from SSL/TLS which I'm hoping that OAuth 2/WRAP takes full advantage of in solving. :-) Right now though, one solution if you are ultra paranoid if you are going to distribute software, is to proxy the calls from your own software through your own web service (which would render the ease of use you get from xAuth moot but you are sacrificing usability for security). Zac Bowling @zbowling
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
> I think you're missing the point, Taylor. It's not a matter of > validation, but actually being able to copy such a long string. I have > trouble with this on mobile, and I think I'm a pretty savvy user. I > *guarantee* you the rate of failure, and giving up on the process > entirely, will be much higher than current auth. > > I can't code some way to sit over the user's shoulder and tell them > "click this, now click that, now spread your fingers_ a bit wider_" If it's a problem with the way the credentials are transmitted, maybe a different or alternative way of transmitting them? E-mail them at the same time, perhaps? A callback URL? -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- If a seagull flies over the sea, what flies over the bay? --
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
On Sat, 12 Jun 2010 09:48:15 -0700 Zac Bowling wrote: > Yes, that is a problem with any app that you distribute that has any > embedded keys. Unfortunately, you ultimately can't really entirely > secure anything you ship that a user can run on their own machine. > You can however take a few steps to make that extremely difficult by > encrypting and obfuscating your consumer keys/secrets in your app > package before you distribute. Nothing is impossible to reverse > engineer if you can get your hands on it (look at iTunes), but you > can make it take so long and be so hard that it becomes to hard and > almost everyone gives up (look at iTunes 9). An important question: secure against what? Against posting tweets when the user is not who they say they are? You can't secure against that. Desktop machines are left unattended. Mobile phones are borrowed and stolen. Sure you can make it harder to just grab the key/secret pair of open source application A and implement application B, pretending to be A. But what does that buy you? What does that protect against? -- Bernd Stramm
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Yes, this is correct. To perform this key exchange, a consumer key (API key) with this feature enabled is all that's required to be stored in your open source app. Some other interesting facts: - A parent application can only spawn 1 version of itself for a user. If the user repeats the flow, their pre-existing app will be returned. - xAuth will not be granted to these keys. For clarity here on why xAuth isn't allowed: having keys out in the public, or easily accessible to the public, that can perform xAuth is absolutely a bad idea. Anyone with a collection of logins and passwords can batch convert them to access tokens, giving themselves access to a member's account regardless of the login and password changing. (This is the other side of the coin.. on one side of the coin you have the advantage that OAuth applications keep working even if the user changes their password (YAY!) and then you have on the side of the coin that OAuth applications keep working even if the user changes their password and they have no idea that they've granted an OAuth access token without their explicit permission (BOO!) ) - Users with suspended accounts cannot create these kind of applications - Applications with suspended status cannot have users create new applications - The result of this process is everything an app needs to function for the user: a consumer key, a consumer secret, an access token, and a access token secret. - We're only allowing open source applications for now. We may consider other use cases in the future. - The user gets an application in this deal. That's actually a big thing. It's not just a row in a database. Addressing a few other points: This process puts the power of the application completely in the hands of the user. Because of this, it's best suited for applications that cater to users with a more advanced understanding of what they're doing. Of course, it's not terribly difficult to perform all the necessary actions, but this feature was not built with a "super-awesome seamless user experience" in mind. It also, naturally, by requiring the user to agree to the API terms of service, comes with other baggage for your users. There are many advantages to this approach from a management perspective for us. It also better shields developers from the actions that can be taken by malicious users, should they reveal their own consumer secrets in their open source apps. We don't want you to do that, that's why we're offering this option. Some users might screw up the copy & paste step. Code defensively. Scrub the input. Verify that it's in the format you think it should be before assuming it's correct. After you parse the tokens, do a verify_credentials API requests or something similar to test if it works. If it doesn't work, try sending the user through the process again (they'll get the same result as the first time). Taylor On Sat, Jun 12, 2010 at 7:12 AM, Cameron Kaiser wrote: > > @taylor > > So key exchange is done based on consumer key only.(No need to verify the > > signature?.Makes sense as this is distributed )So any abuse by the end > user > > will only lead to the ban of child app ? (assuming the final auth > requests > > are signed by the generated secrets (chid app secret and user secret > only) ) > > IDSOWFT, but that is the way I understand it. > > -- > personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- Roger Waters, public health officer: "Careful with that pox, Eugene!" > -- >
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Yes, that is a problem with any app that you distribute that has any embedded keys. Unfortunately, you ultimately can't really entirely secure anything you ship that a user can run on their own machine. You can however take a few steps to make that extremely difficult by encrypting and obfuscating your consumer keys/secrets in your app package before you distribute. Nothing is impossible to reverse engineer if you can get your hands on it (look at iTunes), but you can make it take so long and be so hard that it becomes to hard and almost everyone gives up (look at iTunes 9). One thing I wish was easier though for desktop apps and OAuth is if most API providers would make it possible to have multiple consumers and secrets out for the same app at the same time. You can then rotate new ones in constantly in your builds and if one key is discovered or extracted and abused and revoked, all the versions of your app wouldn't be affected. It's something we do with SSL client certificates against our API when we ship a new build (even each of our nightly builds has its own certificate). If someone extracts it and tries to use it, then we can blacklist that one certificate and it doesn't take down all the versions of our apps. Zac Bowling @zbowling On Jun 12, 2010, at 1:59 AM, Jef Poskanzer wrote: > I don't understand why you are suggesting this only for open source > programs. Were you thinking that an attacker would be incapable of > decompiling an executable and extracting the secret?
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
> Sorry over looked the access token being included. I still do not think this > fits well with open source > desktop apps. I think for now just not distributing a key with the app's > source, but provide it when the app > is built (hidden in the binary or such). That works fine with binaries, but may not work fine with apps written in scripting languages. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I went to San Francisco. I found someone's heart. Now what?
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Sorry over looked the access token being included. I still do not think this fits well with open source desktop apps. I think for now just not distributing a key with the app's source, but provide it when the app is built (hidden in the binary or such). On Sat, Jun 12, 2010 at 10:09 AM, Cameron Kaiser wrote: > > Not sure I totally like this idea. Seems almost like double > authentication > > to me. > > The user has to still sign in via the web to replicate the app and then > we > > have to fetch an access token > > again by asking for their credentials?? So its like doing a 3-legged > dance + > > the xAuth. > > No. The process generates a user access token along with a new "child" app > key in one step. There is no additional xAuth step, and I suspect Twitter > won't want xAuth-enabled app keys to be "childed" in any case. Like any > user > token, it does not expire until the user revokes it, which I assume in this > case will probably never occur since it can only ever be used by the app > key > "child" instance they themselves generated. > > -- > personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- Put down your guns, it's Weasel Stomping Day! > -- >
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
> Not sure I totally like this idea. Seems almost like double authentication > to me. > The user has to still sign in via the web to replicate the app and then we > have to fetch an access token > again by asking for their credentials?? So its like doing a 3-legged dance + > the xAuth. No. The process generates a user access token along with a new "child" app key in one step. There is no additional xAuth step, and I suspect Twitter won't want xAuth-enabled app keys to be "childed" in any case. Like any user token, it does not expire until the user revokes it, which I assume in this case will probably never occur since it can only ever be used by the app key "child" instance they themselves generated. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Put down your guns, it's Weasel Stomping Day! --
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Not sure I totally like this idea. Seems almost like double authentication to me. The user has to still sign in via the web to replicate the app and then we have to fetch an access token again by asking for their credentials?? So its like doing a 3-legged dance + the xAuth. I really question the security benefits of not disclosing consumer key/secrets in the context of desktop/phone based applications. First the xAuth step should be forced to use https which prevents man in the middle attacks. Further all other communication can use https as well. I think the only real security gain from oAuth secrets is for 3-legged authentication. It acts as a cheap verification method that you know this website actually represents this particular application. With desktop/phone applications this is already known since you have downloaded it. When I download client X I know already I am only giving out my credentials to this application, not some attacker spoofing the site. I do appreciate Twitter taking the time to help address these oAuth issues, but before we over complicate the issue lets make sure there are actual gains to be had. Josh On Sat, Jun 12, 2010 at 9:12 AM, Cameron Kaiser wrote: > > @taylor > > So key exchange is done based on consumer key only.(No need to verify the > > signature?.Makes sense as this is distributed )So any abuse by the end > user > > will only lead to the ban of child app ? (assuming the final auth > requests > > are signed by the generated secrets (chid app secret and user secret > only) ) > > IDSOWFT, but that is the way I understand it. > > -- > personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- Roger Waters, public health officer: "Careful with that pox, Eugene!" > -- >
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
> @taylor > So key exchange is done based on consumer key only.(No need to verify the > signature?.Makes sense as this is distributed )So any abuse by the end user > will only lead to the ban of child app ? (assuming the final auth requests > are signed by the generated secrets (chid app secret and user secret only) ) IDSOWFT, but that is the way I understand it. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Roger Waters, public health officer: "Careful with that pox, Eugene!" --
Re: [twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
If the attacker does that, the loser is only that user but not the app (parent app) Basically this idea is to shield the apps from being misused. @taylor So key exchange is done based on consumer key only.(No need to verify the signature?.Makes sense as this is distributed )So any abuse by the end user will only lead to the ban of child app ? (assuming the final auth requests are signed by the generated secrets (chid app secret and user secret only) ) On Sat, Jun 12, 2010 at 2:29 PM, Jef Poskanzer wrote: > I don't understand why you are suggesting this only for open source > programs. Were you thinking that an attacker would be incapable of > decompiling an executable and extracting the secret? >
