mehack

1. On the iPhone, only one app can run at a time. So for a native iPhone app to use oauth it literally has to redirecct the user to a browser session and then close. There's no way to redirect back to the application because it's not running anymore.

This isn't a good user experience, to say the least, and is why all iPhone apps (that I know of) use basic auth still.

How will this be addressed?

2. On this site when I just logged in using oauth, it popped a new browser window that sent me to twitter, but then redirected me back to your site's homepage in that popped up window. So I was left with another window over this page with page I wasn't interested in popped over the content I was reading. Again, non-optimal user experience.

I'm all for oauth. I like the design, i like the security, I like the architecture.

But because it has to be done client-side, it leads to non-optimal user experiences in many cases.

Idealising the stereotypes, a non-techy would either install the first client it finds, or that most of its friends use (I'm guessing the utility of the feature in question would be concentrated in this area): a more *subjective* choice. A techy like myself would see what features each client has, and then make an more *objective* choice. (I've tried so many clients {the popular, the obscure, the flashy}, and have yet to make a firm choice. When I do, it will be on my own volition, not because my friends use it.)

Socialising OAuth might help misguided non-techies, but I think a better solution is a more anonymous "I liked it"-"I didn't like it" system: "this is what the world thinks", though naturally, both can coexist.

Interesting development.

Secondly, what about the idea of an (optional) "API password" for users? Allow them to set it in their profile as a second password that ONLY WORKS for xAuth authentication. If you try to log into Twitter.com using those credentials it fails. This creates a secure way for users to "log in" to xAuth without providing their real password. The only vector for abuse in this case, then, is by storing the API password and being able to re-authenticate a user to the API under a different application's name. Then, to combat that vector of attack, Twitter could simply provide a log of xAuth authentications performed for a given user, allowing them to track and remember when they may not have specifically authorized an application.

There could even be an optional e-mail notification whenever an xAuth is performed against their account. I think it would be interesting in general to have e-mail notifications when applications are added to your account, just a "Hey this application was just added. If you didn't do it, let us know!"

Anyways, I think this system would provide a robust and secure foundation for the xAuth methodology without compromising ease-of-use.

Also remember PGP for E-Mail? Nobody is using it because in most cases the user experience just is just bad. And I mean bad like in BAD. So what's the point about having a service where you have the greatest UE in the world, but nobody is using it?

Informing users about the possible threats is a much better way in my opinion to take care of the ever rising threat to their credentials. Having "dumb" users that are just protected by their browser doesn't help the developers, nor does it help the users.

Thanks for the link to my blog, but I couldn't disagree any more strongly with almost 100% of what you just wrote.

- i disagree that security is related the size of company. if true, shouldn't we all be using Facebook?

- i disagree that sending your passwords through a web browser is safer. ALL of the malware that i've come in contact with comes through the browser. saying the browser is safer is ignoring the real world.

- i disagree that "popular" can be translated to safer. the reason phishing techniques work so well is because they become popular very quickly. popularity is an easy metric to game.

But mostly, I disagree with a single underlying assumption: That my password is a significantly valuable commodity on my machine.

Don't get me wrong. A Twitter password is very valuable. My banking password even more so.

But when I download a twitter client, or a mail client, or even just a new game I have to trust that it will not send the entire contents of my user directory to some evil people. The contents of my user directory contain browser caches, financial documents, personal pictures -- LOTS OF STUFF that I'd prefer not to share. That stuff is WAY WAY WAY more valuable than access to twitter.

Here's a thought experiment: which would be the tougher loss -- the contents of your bank account or your family photo album?

That's the amount of trust that you give every piece of software you run on your machine.

Yes, signing authority and sandboxed apps (e.g. iPad) is a way forward, but we're not there yet and there are many mountains to climb along the way.

Right now, a personal computer does require that you trust the software you run on it. Building a system on top of something that ignores this reality is just security theater.

Isaiah

I think the main problem with OAuth is that it's over-complicated while the benefits for users are really low.

The "inherent danger" of entering a password into a native application is only true for people who use the same password for every service - be it GMail, their banking account, etc. OAuth actually tricks people to believe their (simple) password is safe - while it just isn't.

Comparing the risks between plain password and OAuth, there's basically little difference. You'll only notice the "fraud" once the damage has been done (tweeting spam, following people, ...) The counter-action is similar: you change your password - or you revoke the OAuth access. If you've used the same password for all your accounts, you've got a bit more to do, granted :-)

I think xAuth is a good compromise - especially for us mobile client developers with platforms where we cannot easily open a browser or where the browser generally sucks. However, technically and from a security perspective it's nothing else than Basic Auth.

So why don't you add a special "API" or "Application" password for each account. Wouldn't that make sense?

As a side note: what do you think, how long will it take for someone to create a fake OAuth authorization site of twitter.com/oauth/authenticate for fishing passwords? :-)

I think a user-defined API password makes sense and wouldn't be too confusing (especially if it were an optional feature for those particularly concerned about security).

I wrote to api@twitter.com to inquire about how I may get my shell-based software on the new xAuth system. I was told that I needed to make my software use OAuth first and only then will I be permitted to use xAuth.

I'm not really sure what to do at this point. I guess I could write some throwaway code one time to go through the OAuth motions. But if I'm going to do that, I may as well just write robotic user agent code to push the Allow button on Twitter's OAuth page for the user, and then forget about xAuth.

I feel like my work is being excluded for not being a web-application or being able to closely integrate with a browser. I wish this was less difficult for developers.