I agree with Cameron that OAuth is the way to go for web-based Twitter API apps. I think those are the most problematic security-wise, and with all due respect to people who have developed these web-based apps that require Twitter authentication credentials, that they are doing a disservice to their users by training them to get phished. Also, had the opportunity to audit many web sites in my day, and I've examined the practices of several web apps that utilize Twitter user credentials, and my overall impression is that the vast majority of people making these apps have little or no awareness of the security issues they face, or how to address them.
Were I king of Twitter, I would have banned any 3rd-party web sites that request usernames and passwords. Lucky for you, I'm not in charge 8D. The security expectations are different for desktop apps, I think. Users understand the potential for malicious applications on the desktop better, and that's why I never had a problem asking for a username and password in Spaz, as long as I always communicated over SSL, and stored the password locally in an encrypted format. Desktop apps are typically not open to as many easy-to-execute attacks that would allow for stealing of credentials as web apps. So, I feel comfortable with desktop apps requesting usernames and passwords. I also think that throwing the OAuth authorization squaredance would indeed be a hassle that will confuse most users – maybe not as much as OpenID does, but something that definitely will require a lot more hand-holding and explanation on the part of app devs. However, I don't know if it's reasonable or even possible to make a distinction between web apps and desktop apps for the purposes of authentication type. I suspect it is not. OAuth does offer some wins over username/password exchange. As I understand it (mostly from my experience with Flickr), these include: - more granularity over authorization: an application can just request read access, for example - no password sharing required: many (most?) users will duplicate usernames and passwords across various accounts. OAuth limits the potential damage (although you could see some interesting information assurance problems with Twitter accounts that feed other systems). - A malicious app can be blocked system-wide (after being identified as such) - A malicious app can be blocked from an account without changing that account's username and pass (after being identified as such) All that being said, *I will bet you dollars for donuts that you'll see successful phishing attacks via OAuth*. In fact, you might even see *more* successful attacks, because for as many folks who have ill-advisedly entered their Twitter credentials into a 3rd-party site to get an ego-stroke, I suspect that *more* will click a button that says "give this application permission," no matter what permissions are being requested. Those who expect OAuth to be a panacea for identity theft on Twitter simply don't understand the issues involved. Operating a modern computer involves a lot of trust - trusting applications you run on your machine, trusting web sites you set up accounts on, and the like. And when you trust, there's always the potential for getting burned. OAuth doesn't change that fundamentally. In addition, OAuth or no, what makes us think classic phishing attacks that collect Twitter usernames and passwords will stop? Remember, *most Twitter users use the web site or SMS* and therefore may have *no* interaction with the OAuth system -- all they ever do is enter a username and password. And even for folks who *do* have experience with the OAuth system, I'd expect that without extensive training, they'd still be likely to fall for classic phishing attacks. As a side note, I wonder if Twitter API dev would have taken off as it did if OAuth was required from the start. I believe that using HTTP Basic Auth was a key to making API dev as accessible as possible. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Sun, Jan 4, 2009 at 5:07 PM, Cameron Kaiser <spec...@floodgap.com> wrote: > >> We'll certainly be doing our utmost to incentivize developers to move >> to OAuth. The next major version of the API will be OAuth-only, for >> example. > > This is where I get antsy, and maybe Chris can point out some ways to deal > with this, but from my perspective as a desktop client author OAuth is a > lot of hurt without a lot of benefit to me the developer (other than "it's > the only way in so love it or lump it"), and I think even the user's benefits > are nebulous. If you don't trust an application, you shouldn't be running it. > Isn't that where Trojan horses come in? > > But let's say that there is (a) good reason for a desktop application to use > OAuth as its primary method; now I have a technical question. The way I'm > reading > > http://oauth.net/core/1.0/ > > is that I go and get a request token (A.2), but I need to redirect a user to > a service provider's login page (ouch) for her to authorize that token (A.3), > then provide a callback URL (double ouch) (A.3). At best this is turning my > application into not only a Twitter client, but also a web server (to accept > the callback). At worst this isn't possible because the Service provider > *can't* call me back due to network restrictions on the desktop machine. > Also, since TTYtter is text based, I *really* don't want to be opening up a > browser to get logins (or if I do, I want it to be Lynx, and fat chance I > bet). > > Clearly OAuth is the way to go for standalone web sites talking to Twitter, > but I get nervous about hearing OAuth will be the only method of access while > trying to work through the issues unique to a desktop client. I would > appreciate hearing from someone knowledgeable about the best way to overcome > these issues, or if there is a special way that I missed where an application > can authenticate itself by just asking the user for their OAuth credentials > and proxy everything to the service provider, which would also suck, but less, > from a developer standpoint. (But that would also probably defeat the purpose > of OAuth.) > > -- > ------------------------------------ personal: http://www.cameronkaiser.com/ > -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com > -- Blanket statements are always wrong. > --------------------------------------- >
