ns
> 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 res
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, r
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
Eran Hammer-Lahav wrote:
> You are looking at it wrong.
>
> (insert IANAL disclaimer here)
>
> Yahoo! Issues client credentials to a specific, authenticated user. That
> user has accepted our legal terms which include not sharing those
> credentials with anyone else. If you break this agreemen
You are looking at it wrong.
(insert IANAL disclaimer here)
Yahoo! Issues client credentials to a specific, authenticated user. That user
has accepted our legal terms which include not sharing those credentials with
anyone else. If you break this agreement (which is a legally binding contract),
Allen Tom wrote:
> Martin Atkins wrote:
>> Indeed, but if for example I take the oauth consumer key and secret out
>> of the Movable Type FireEagle plugin and use it in my service then I can
>> use FireEagle without agreeing to the legal terms
>
> Sure, but the developer that was issued the CK
Martin Atkins wrote:
> Indeed, but if for example I take the oauth consumer key and secret out
> of the Movable Type FireEagle plugin and use it in my service then I can
> use FireEagle without agreeing to the legal terms
Sure, but the developer that was issued the CK had agreed to the terms,
Eran Hammer-Lahav 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 b
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:
tion.
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-
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
But it does make the lawyers happy.
EHL
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Martin Atkins
> Sent: Wednesday, March 25, 2009 10:35 AM
> To: oauth@googlegroups.com
> Subject: [oauth] Re: Security
Allen Tom wrote:
>
> 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 serve
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
I don't know too much about Flickr Auth, but I'm pretty sure that the
Flickr API Key (aka consumer key) and the secret are baked into desktop
apps.
One thing to consider is that the user had to download and install the
app in the first place, so given that the user trusted the app enough to
d
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/downgra
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 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
pati
On Sun, Mar 22, 2009 at 3:37 PM, Nial wrote:
>
> I've been working on some JS that works as an OS X dashboard widget.
> The widget connects to a third-party service which requires OAuth
> authorization.
>
> In regards to the Consumer Key/Secret, as far as I understand it,
> these two pieces of in
19 matches
Mail list logo
