On 9/1/2010 7:47 PM, Julio Biason wrote:
OAuth certainly makes sense as a model for "never type your password
in some weird site 'cause you don't know when they say that they
couldn't connect to Twitter is really that or they are just storing
your login and password to abuse the ecosystem". The
On 9/1/2010 7:01 PM, Julio Biason wrote:
On Wed, Sep 1, 2010 at 9:56 PM, John Meyer wrote:
And rendering the key useless to the spammer.
And to you. And your users.
That's the whole problem with it. Yes, one could simply strings(1) one
Mac app and probably retrieve the keys and spam the hell
On Wed, Sep 1, 2010 at 10:20 PM, John Meyer wrote:
> 1. reverse engineering a consumer key combo from a legit program, creating
> user accounts and generating tokens, spamming it until it's locked out,
> tracking down another legit program, reverse engineering it, lathering,
> rinsing, and repeat
On 9/1/2010 7:01 PM, Julio Biason wrote:
That's the whole problem with it. Yes, one could simply strings(1) one
Mac app and probably retrieve the keys and spam the hell of Twitter
with it. For the spammer, it doesn't matter if the key is revoked as
he could just get another one; the real problem
On Wed, Sep 1, 2010 at 9:57 PM, John Meyer wrote:
> That's the way Twitter Tools for Wordpress works, and it isn't ackward at
> all. It's description leaves something to be desired, but it ain't rocket
> science.
WordPress users are "a complete different beast" than desktop users.
Even if you us
On Wed, Sep 1, 2010 at 9:56 PM, John Meyer wrote:
> And rendering the key useless to the spammer.
And to you. And your users.
That's the whole problem with it. Yes, one could simply strings(1) one
Mac app and probably retrieve the keys and spam the hell of Twitter
with it. For the spammer, it do
On 9/1/2010 6:46 PM, Julio Biason wrote:
On Wed, Sep 1, 2010 at 7:58 PM, John Meyer wrote:
And that assumes that you distribute the consumerkey and consumersecret with
the app. Nothing about Open Source requires this. You could just as easily
just distribute the source and require that users
On 9/1/2010 6:03 PM, Mike Desjardins wrote:
Yes, and your application's consumer secret ends with the following
characters: jOU
I obviously know the entire string and have the good sense not to
reveal it here. The point is, it's trivially easy for me or anybody
else to unzip your "packaged dow
On Wed, Sep 1, 2010 at 7:58 PM, John Meyer wrote:
> And that assumes that you distribute the consumerkey and consumersecret with
> the app. Nothing about Open Source requires this. You could just as easily
> just distribute the source and require that users obtain their own
> ConsumerKey combos.
I have an open source Twitter client for Google Chrome and this is how I
distribute it.
The source is available with no API key. If developers wish to play with the
source they must register their own OAuth application.
http://github.com/abraham/omnitweet
For users there is a packaged download t
On 8/19/2010 11:50 AM, briandunnington wrote:
as Julio stated above, the official response from Taylor (in another
thread) was that this solution will *not* be rolled out. there is
currently no other alternative being offered other.
and just to repeat what has already been said a few time in thi
On Mon, Aug 9, 2010 at 1:50 PM, Meepnix wrote:
> Has this solution for Open Source applications using OAuth with the
> Twitter API been implemented yet? As the deadline for Basic
> authentication removal is looming very close; 16th August, end of this
> week.
On another thread, Taylor said "No".
The answer is soon! :) We hope to roll this out more widely this week.
On Mon, Jun 28, 2010 at 7:56 AM, Decklin Foster wrote:
> Taylor Singletary wrote:
> > We're waiting on a few minor bug fixes to be in place before rolling this
> > out to a wider audience. I'll post a new message when things a
Hi Everyone,
We're waiting on a few minor bug fixes to be in place before rolling this
out to a wider audience. I'll post a new message when things are good to go
and we're ready to accept applications into the feature.
Taylor
On Sun, Jun 20, 2010 at 1:30 AM, nov wrote:
> Hi, Twitter API team
Interesting details, and see below:
On Mon, 14 Jun 2010 10:51:34 -0700
Zac Bowling wrote:
> In facebook's desktop authflow, rather then giving you an
> ...
> Basically when it comes to desktop apps, Facebook can't for sure tell
> the difference between my desktop app and illegitimate one.
Not
In facebook's desktop authflow, rather then giving you an access_token endpoint
to call with a secret to exchange a callback and get an valid access_token, you
instead call authorize and it will redirect the user to a login_success.html
page on facebook.com with the access token in a fragment on
Right, and...
On Sat, 12 Jun 2010 16:09:47 -0700 (PDT)
Jef Poskanzer wrote:
> You know, it's right there in the OAuth RFC.
>
> http://tools.ietf.org/html/rfc5849#section-4.6
>
> 4.6. Secrecy of the Client Credentials
>
>In many cases, the client application will be under the control of
>
Quoting funkatron :
Yeah, it's really the step of manually getting that long string of
seemingly-random characters from one app to another. a callback url
makes sense for web-based apps.
Something like PIN auth that would allow a desktop/mobile app to make
an HTTP call and recover the string pr
On Jun 12, 2010, at 3:05 PM, Bernd Stramm wrote:
>> I've been pondering how you could solve this from my experience with
>> solving these issues with SSL/TLS. One idea is having a sort of
>> delegation chain where I could generate a new delegated secret for
>> each copy of my app I distribute rathe
On Sat, 12 Jun 2010 13:25:44 -0700
Zac Bowling wrote:
> On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> > Application authors are being asked to devote substantial resources
> > to the OAuth conversion, but OAuth provides no security for
> > application authors!
>
> It does from a web app p
> Yeah, it's really the step of manually getting that long string of
> seemingly-random characters from one app to another. a callback url
> makes sense for web-based apps.
>
> Something like PIN auth that would allow a desktop/mobile app to make
> an HTTP call and recover the string programatical
On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
> Application authors are being asked to devote substantial resources to
> the OAuth conversion, but OAuth provides no security for application
> authors!
It does from a web app perspective which is the primary design goal of OAuth
since there wo
> I think you're missing the point, Taylor. It's not a matter of
> validation, but actually being able to copy such a long string. I have
> trouble with this on mobile, and I think I'm a pretty savvy user. I
> *guarantee* you the rate of failure, and giving up on the process
> entirely, will be muc
On Sat, 12 Jun 2010 09:48:15 -0700
Zac Bowling wrote:
> Yes, that is a problem with any app that you distribute that has any
> embedded keys. Unfortunately, you ultimately can't really entirely
> secure anything you ship that a user can run on their own machine.
> You can however take a few steps
Yes, this is correct. To perform this key exchange, a consumer key (API key)
with this feature enabled is all that's required to be stored in your open
source app.
Some other interesting facts:
- A parent application can only spawn 1 version of itself for a user. If
the user repeats the flow, t
Yes, that is a problem with any app that you distribute that has any embedded
keys. Unfortunately, you ultimately can't really entirely secure anything you
ship that a user can run on their own machine. You can however take a few steps
to make that extremely difficult by encrypting and obfuscati
> Sorry over looked the access token being included. I still do not think this
> fits well with open source
> desktop apps. I think for now just not distributing a key with the app's
> source, but provide it when the app
> is built (hidden in the binary or such).
That works fine with binaries, but
Sorry over looked the access token being included. I still do not think this
fits well with open source
desktop apps. I think for now just not distributing a key with the app's
source, but provide it when the app
is built (hidden in the binary or such).
On Sat, Jun 12, 2010 at 10:09 AM, Cameron Ka
> Not sure I totally like this idea. Seems almost like double authentication
> to me.
> The user has to still sign in via the web to replicate the app and then we
> have to fetch an access token
> again by asking for their credentials?? So its like doing a 3-legged dance +
> the xAuth.
No. The pro
Not sure I totally like this idea. Seems almost like double authentication
to me.
The user has to still sign in via the web to replicate the app and then we
have to fetch an access token
again by asking for their credentials?? So its like doing a 3-legged dance +
the xAuth.
I really question the s
> @taylor
> So key exchange is done based on consumer key only.(No need to verify the
> signature?.Makes sense as this is distributed )So any abuse by the end user
> will only lead to the ban of child app ? (assuming the final auth requests
> are signed by the generated secrets (chid app secret and
If the attacker does that, the loser is only that user but not the app
(parent app) Basically this idea is to
shield the apps from being misused.
@taylor
So key exchange is done based on consumer key only.(No need to verify the
signature?.Makes sense as this is distributed )So any abuse by the en
32 matches
Mail list logo
