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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
