Comments on: OAuth Alternative for Twitter

By: andrewluetgers

andrewluetgers — Sun, 21 Aug 2011 19:05:53 +0000

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!

By: Backdrifter: Google Offers OAuth Alternative to Improve Security

Backdrifter: Google Offers OAuth Alternative to Improve Security — Thu, 10 Feb 2011 22:22:08 +0000

[...] sounds an awful lot like PAuth, which Don Park suggested as an alternative to OAuth over two years ago. I’ve always wondered [...]

By: Dominique

Dominique — Sun, 24 Oct 2010 10:12:51 +0000

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.)

By: Tim Gets Your Apps Talking Securely at Acts As Conference 2009

Tim Gets Your Apps Talking Securely at Acts As Conference 2009 — Wed, 14 Jan 2009 14:00:34 +0000

[...] to allow application access rather than usernames and passwords. Bloggers including Louis Gray and Don Park have suggested that Twitter implement OAuth, and there’s been more discussions on Chris [...]

By: Don Park

Don Park — Tue, 06 Jan 2009 14:12:11 +0000

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.

By: Blaine Cook

Blaine Cook — Tue, 06 Jan 2009 11:14:56 +0000

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.

By: donpark

donpark — Tue, 06 Jan 2009 05:58:25 +0000

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.

By: Kevin Marks

Kevin Marks — Tue, 06 Jan 2009 05:51:14 +0000

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.

By: donpark

donpark — Tue, 06 Jan 2009 05:26:35 +0000

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.

By: Kevin Marks

Kevin Marks — Tue, 06 Jan 2009 05:18:13 +0000

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.