The obvious solution (pun intended) to Twitter auth problem is OAuth. As Biz wrote, OAuth won’t prevent hacking but should reverse increasingly common practice of third-party software and services asking for Twitter credentials. However, OAuth is a disruptive change, one that will break existing code and force everyone to change over. In this post, I will propose a practical alternative to OAuth that offers smoother transition.
PAuth
The core idea behind PAuth is to continue using password for auth but allow multiple passwords to exist for an account, each potentially bound to specific set of clients and permissions.
The key advantage PAuth offers to fast moving services like Twitter is that no client software change is necessary.
User Experience
- User wants to use Twhirl but, to enable it, Twitter username and password is necessary.
- User signs into Twitter with primary password and proceeds to creates generate a limited password for Twhirl, enabling only the permissions Twhirl needs.
- User uses the limited password to enable Twhirl.
- When user stops using Twhirl, limited password for Twhirl is deleted.
Multiple Posters
An interesting use of PAuth is limiting password to post-only. By issuing each poster a post-only password, multiple users will be able to post to a single Twitter account and admin (primary password holder) will be able to ban individual posters at any time without affecting other posters.
Details
Limited passwords should be generated for convenience and security. Since limited passwords are maintained by the PAuth provider and typically copy/pasted over to consumer site/client, it can be longer than usual passwords also.
Don Park's Weekly Habit 
Yet another ‘Authentication without Authorization’ idea. Or rather a ‘get the user to do the auth management protocol’. Users already use the same password for multiple sites – what makes you think they’ll bother to manually bounce back and forth to twitter to create a per-domain token rather than let OAuth do the exchange for them, with all that signing and shiny cryptography.
Hi Kevin. Long time no see. I expect lazy users to continue to use primary password, paranoid users to use limited passwords all the time, and most users to choose depending on perceived security of the consumer site/client where choices are: primary, limited, or don’t use.
I just don’t think OAuth is appropriate when there is a huge body of third-party software and services that need to change.
Well, we shipped OAuth for all Google APIs so they can change. If Twitter hadn’t put OAuth on the backburner 9 months ago they would be further along with it.
True. I am writing new Twitter client code (again) now so I definitely could use it but that’s not the case for all the code and services built around Twitter already. It’s a business decision I think although I don’t see any problem with doing both. PAuth w/o fine-grained permission should be doable in a week.
Implementing OAuth for Twitter isn’t a big deal – it’s the documentation, rollout, and communication with users that’s the trouble. Likewise, client developers won’t have much difficulty adapting their stuff to work with OAuth, since it’s a simple workflow change and the addition of a wrapper around the HTTP requests they’re making.
PAuth is certainly simpler for client developers, but would require more of the “hard” documentation / communication work from Twitter. How do you explain to users that they should get new passwords for all their existing apps, particularly when you have no way of identifying said applications? What does the UI look like for that, and have existing apps been built to adequately deal with password changes?
Once all that’s said and done, PAuth is less secure than OAuth – I can still steal your password from an open wifi cafe every time Twitteriffic makes a request.
I think what’s needed overall is more and better documentation of secure protocols. This conversation and others like it is helping to further awareness about the reasons, options, and pitfalls for and of security on the web, which is good for everyone.
Hey, Blaine. What are you cooking at Yahoo? ;-p
Sure, PAuth is less secure than OAuth. But, heck, it’s just as secure as Twitter website login. Like I said, it’s a biz decision in the end.
Agreed on conversation greasing the path toward goodness for everyone.
I’ll gear this review to 2 types of people: current Zune owners that are considering an upgrade, and people attempting to decide between a Zune and an ipod. (There are more players worth considering out there, such as the Sony Walkman X, but I really hope thus giving you enough info to make the best decision from the Zune vs players other than ipod and iphone line as well.)
Ive been trying to wrap my head around OAuth and have communicated with Eran Hammer-Lahav who is a key contributor to OAuth and yet i feel no more secure for his responses http://hueniverse.com/questions/#comment-34601. To be more specific I’m speaking of oAuth, in any incarnation (1.0, 1.0a, 2.0), when applied to anything that is not a web server. iPhone, Android and desktop apps as well as stand alone web apps (off line html, js, css) and browser plugins all suffer from the problem of exposing their client key and “secret” in some cases in plain text, in other cases it can be retrieved easily enough by decompiling the distributed binary files. Its my belief that to be honest with ourselves we need to recognize the client key and “secret” are public information in these configurations. A simple question for you: is it a problem for the client key and secret to be public? I think the answer is clearly yes.
I believe this issue leaves OAuth susceptible to phishing style attacks where an evil app masquerades as a trusted app. This problem does not exist if the third party app is a web site because the client key and secret are kept hidden on the server. Also in the case of a browser we have the built in ssl certificate information we can check and the url of course. In the big world outside the browser we have no such assurances. Furthermore native apps that kick a user out to a browser session are not secure either because they can mimic the appearance of a browser or simply pull strings behind the scenes to log keystrokes. Nick (sorry i don’t have his last name) has done some excellent work pointing out this risk http://nicksnettravels.builttoroam.com/post/2011/03/26/Hack-OAuth-security-flaw-for-Windows-Phone-7-iPhone-and-other-Mobile-platforms.aspx
Do you agree there is actually a risk of evil apps using trusted app client keys and secrets to steal data they otherwise would not have had access to or do i misunderstand the spec?
I have been working on a variant of PAuth to try to mitigate this risk that also solves some of the user experience issues others have cited. Id love to discuss more if you’d like pleas email me.
Thanks so much!