[oauth] Re: Security through obscurity?
This is not an OAuth issue by how it is implemented. There is nothing to prevent servers from not requiring registration. It is part of the discovery spec. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Martin Atkins Sent: Thursday, March 26, 2009 4:38 PM To: oauth@googlegroups.com Subject: [oauth] Re: Security through obscurity? Eran Hammer-Lahav wrote: Comparison with OpenID at this stage is not that relevant because while OAuth protects real data and resources, OpenID at most reveal some silly information about you (SREG). So it is ok to let the use decide how they share some minimal set of data about them, read only, and without updates. Not so much when you can access their electronic wallet... As a user I cannot grant access to my data to applications I trust if the application vendor has not made a business deal with the company that's hosting my data. I can't host my own data because OAuth is set up in such a way to require every combination of (consumer, provider) to be pre-registered out of band, and no application vendor is going to have pre-registered with my one-off, self-hosted data service. So I'm stuck. I can't force the application vendor to agree to the service provider's terms, and I can't provide my own service. What am I supposed to do? The electronic wallet example is a distraction because OAuth as deployed today is used for much less critical things like updating my location in FireEagle, or retrieving the data from my address book on GMail. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
Both of you are right. Technically there's no irrefutable way to prevent leaking tokens in desktop apps, so forcing pre-registration is simply a way to get developers to agree not to casually release what qualifies as confidential information. If you do leak said information (i.e. By embedding it in your desktop app) you agree to hold harmless the SP that provided you the token if/when they shut off your key. The two solutions are complements. Whether the legal solution fully recognizes the limitations of technical solution is another story. Chris On 3/25/09, Eran Hammer-Lahav e...@hueniverse.com wrote: That's simply not true. When you manually register an application you agree to legal terms with how you may or may not use the user's data you are accessing and other legal requirements. Without this agreement, users could sue the service provider for bad acts by the application. EHL -Original Message- From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf Of Martin Atkins Sent: Wednesday, March 25, 2009 12:28 PM To: oauth@googlegroups.com Subject: [oauth] Re: Security through obscurity? Eran Hammer-Lahav wrote: But it does make the lawyers happy. Maybe the lawyers ought to listen to the technical folks telling them that requiring pre-registration of desktop apps achieves nothing whatsoever. It can't be healthy to have lawyers who believe they have an effective mechanism that is in fact completely ineffective. -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
On Mar 23, 2009, at 12:19 , Nial wrote: It seems like the best way to move forward would be to have my widget contact my server and check for a change in consumer key/secret. Of course, it'd be easy for anyone to visit that address for the latest details, but it'd mean less hassle for the end-user. This may be less relevant in this particular discussion, but if you're dealing with web-based widgets, a server call could be used to authenticate the Consumer without using a secret. I wrote down some ideas about a potential solution here: http://supercollider.dk/blog/2009/01/oauth-and-client-side-widgets -- Mark Wubben http://supercollider.dk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
I think that it ultimately depends on your security model and needs. If the benefit of hacking your consumer key is minor, then it's probably not that big a deal if it leaks; if you change your consumer key for every major or minor release, you'll at least be able to track usage and upgrade/downgrade permissions on a rolling basis That is, say you release v1.2 of your app with a new consumer key, you could deprecate v1.1's consumer to be used only for read operations — meaning that the user needs to reauthorize the app to gain full write functionality. This seems reasonable to me, and with work, could be made to be a fairly routine behavior. There's much made of security and making software watertight, but I find that most successful systems tend to be more lenient and accommodating and provide a mix of security with ways to recover when things go wrong. The solution above doesn't prevent all manner of attacks from happening, but at some point, you have to just take that risk and develop ways to mitigate against them. Maybe Allen can speak to how Flickr deals with this with both their Flickr Uploadr and the iPhoto '09 integration? Surely they have consumer keys? Chris On Mon, Mar 23, 2009 at 4:19 AM, Nial nia...@gmail.com wrote: It seems like the best way to move forward would be to have my widget contact my server and check for a change in consumer key/secret. Of course, it'd be easy for anyone to visit that address for the latest details, but it'd mean less hassle for the end-user. On Mar 23, 1:42 am, Allen Tom a...@yahoo-inc.com wrote: So how does this 3rd party server authenticate your widget? What's to stop someone from reverse engineering the protocol and requesting your CK/Secret? We believe that it is impossible to safeguard any secrets embedded in downloadable client applications. Someone with a debugger and some patience will be able to extract the secrets very quickly. Likewise, any secret protocol between a downloadable client and a server can also be easily reverse engineered. Therefore, it's impossible to securely identify a client application, and a downloadable client application's consumer key (even when signed with its consumer secret) is about as meaningful as your browser's HTTP User-Agent string. Unlike downloadable client applications, server based apps are able to safeguard their consumer secret, so it is possible to authenticate server based applications. Allen Nial wrote: This opens the question of whether or not to store my consumer key/ secret within the widgets JS files or request them from a third-party server as and when the widget is initialized. If I were to do the former (as I am currently), I'd have to put out a new version of my widget if my old consumer key/secret were compromised. Which I suppose begs the question: how often do such things occur? -- Chris Messina Citizen-Participant Open Web Advocate factoryjoe.com // diso-project.org // vidoop.com This email is: [ ] bloggable[X] ask first [ ] private --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: Security through obscurity?
So how does this 3rd party server authenticate your widget? What's to stop someone from reverse engineering the protocol and requesting your CK/Secret? We believe that it is impossible to safeguard any secrets embedded in downloadable client applications. Someone with a debugger and some patience will be able to extract the secrets very quickly. Likewise, any secret protocol between a downloadable client and a server can also be easily reverse engineered. Therefore, it's impossible to securely identify a client application, and a downloadable client application's consumer key (even when signed with its consumer secret) is about as meaningful as your browser's HTTP User-Agent string. Unlike downloadable client applications, server based apps are able to safeguard their consumer secret, so it is possible to authenticate server based applications. Allen Nial wrote: This opens the question of whether or not to store my consumer key/ secret within the widgets JS files or request them from a third-party server as and when the widget is initialized. If I were to do the former (as I am currently), I'd have to put out a new version of my widget if my old consumer key/secret were compromised. Which I suppose begs the question: how often do such things occur? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups OAuth group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
