I wasn't thinking about downstream requests where you still need both
tokens, just token requests ... yeah, that's rough.
On Sat, Jul 4, 2009 at 10:38 PM, Dossy Shiobarado...@panoptic.com wrote:
On 7/4/09 5:30 AM, Andrew Badera wrote:
I haven't done much real desktop OAuth, mostly web ...
Hint: This isn't a dilemma for only open source developers. It's a real
and serious problem for any application whose code (source or object) is
accessible to anyone other than the application developer,
i.e., any application that the user installs.
It should take all of, what, a day, to
I haven't done much real desktop OAuth, mostly web ... but can't you
simply proxy the request through your own server, and keep the secret
on your server, serving client requests centrally?
Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera
- This
That's certainly a technical possibility.
But I've got to create an authentication scheme for the users to log into my
proxy.
Then I have to set up hosting.
Then I have to write a second application to handle the requests from my
client and send the responses back.
So simply is not an accurate
On 7/4/09 5:30 AM, Andrew Badera wrote:
I haven't done much real desktop OAuth, mostly web ... but can't you
simply proxy the request through your own server, and keep the secret
on your server, serving client requests centrally?
Yes, yes you can - then you get to enjoy the Twitter rate limit
It seems as though revealing the Consumer Key and Consumer Key Secret
of my application would be a pretty serious security risk. Anyone
could write an application that impersonates mine, but they still
would need an authorized user's Token and Token Secret in order to
commit mischief.
What sort
I do not feel you've made a mountain out of a mole hill here. This
topic has been on my mind since I first encountered oAuth. I haven't
seen any open source apps use oAuth yet.
We have an open source application called Application X. The
potential risk is that Application X becomes widely
If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/
core/1.0#anchor4) states it pretty plainly:
Service Providers SHOULD NOT rely on the Consumer Secret as a method
to verify the Consumer identity, unless the Consumer Secret is known
to be inaccessible to anyone other than the
The secret should not reside in code. The secret should reside in a
config file, or maybe even a machine datastore. Abstract it out, no
one ever needs to see anything secret in your code.
Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera
- This
That's not correct. Updates posted to Twitter via Basic Auth always
appear with a source of From Web (unless the application in question
was grandfathered in). Otherwise, it's not possible to impersonate
another application via Basic Auth.
On Jul 1, 9:34 am, Abraham Williams 4bra...@gmail.com
True, but none of that addresses the central points that I'm trying to
make:
1. The OAuth Core documentation says that providers should not rely on
the Consumer Secret to identify consumers.
2. Twitter's implementation of OAuth appears to do exactly what the
OAuth Core documentation says not to
Might sorta work on webapps, or maybe desktop compiled code (assuming
the config is compiled in at build time), but that doesn't help for
desktop apps written in interpreted langs, where all source code and
configs would be easily viewable (although I could imagine some
initial setup stuff where
Andrew,
The Consumer Secret is the key that has to be associated with my
application so that it can authenticate to Twitter. Regardless of how
I distribute it, I still have to distribute it with the source code in
order for the source code to work.
No amount of abstraction will prevent someone
Yes, but don't distribute it. Obviously config files are human
readable, but you blank out secrets before publishing them.
People using open source libraries will have to get their own keys.
So, either you really are contributing in the spirit of open source,
and you don't care about
Andrew,
I'm not talking about a -library-. I'm talking about a -client-. If
I want to produce a Twitter client, it needs its own Consumer Key and
Consumer Key Secret. If want to share the source code for that
client, I will also have to share it's Consumer Key and Consumer Key
Secret.
You
The worst that happens if you publish the consumer tokens in an
opensouce app is someone malicious uses it to abuse Twitter and the
consumer token gets banned. At which point you regenerate a new one
and push a new version of the app. The cycle may or may not start
again depending on the
Not what I said in the least, but it's interesting that you should
interpret it that way.
Re-read what I said.
If someone is open sourcing something, in the true spirit of open
source, they shouldn't care about getting credit in the source
parameter.
Thanks you and good night, I'm here all
Not what I said in the least, but it's interesting that you should
interpret it that way.
Re-read what I said.
If someone is open sourcing something, in the true spirit of open
source, they shouldn't care about getting credit in the source
parameter.
Tell that to Richard Stallman.
--
Andrew,
This isn't about credit in the source parameter. It's about
application security.
Twitter has stated that Basic Auth will eventually be deprecated.
OAuth will eventually be the only method of authentication available.
When that happens, developers of open source clients will be forced
Amen and thank you Matt.
On Wed, Jul 1, 2009 at 11:09 AM, Matt Sanfordm...@twitter.com wrote:
On Jul 1, 2009, at 5:10 AM, Philip Plante wrote:
I do not feel you've made a mountain out of a mole hill here. This
topic has been on my mind since I first encountered oAuth. I haven't
seen
A technical solution I see working is a modified PIN flow where
instead of a 6 digit PIN the user gets a 20 character token that acts
as consumer token. No harder then using PIN flow but each desktop
install would have a unique consumer sub token that could still be
tied into the global consumer
Sounds like the assumption is that part of the keypair is in the
source. That is clearly a bad idea ... The software should obly
provide for processes and not ever content
Sent from my iPhone
On Jul 1, 2009, at 11:10 AM, Andrew Badera and...@badera.us wrote:
No one's snarking, but
Nancy,
You're right - it is a bad idea. However, it appears to be the only
option that Twitter has left to open-source developers who wish to
implement OAuth. There doesn't seem to be any way around distributing
my application's Consumer Key Secret.
Regards,
Duane
On Jul 1, 11:17 am, Nancy
The problem is that by everyone getting their own consumer keys, the source
parameter will be different for every person. Now, I'm not interested in
getting my name in lights in the Twitter world -- I could honestly care
less. That said, if I'm going to spend a significant portion of my time
Actually, since Twitter has said that Basic Auth will eventually go
away, OAuth is going to be the only choice for authentication.
Twitter has forced the choice by implementing OAuth in the way that
they did.
Why should a user who chooses to support open source by using an open-
source Twitter
How difficult is it to, as part of the build, check for a key file, if
it doesn't exist, go to Twitter and do the stuff to get the tokens,
parse the tokens and save in the key file, and then continue on with
the build. Seems easy enuff.
-- Bruce
Sent from my iPhone
On Jul 1, 2009, at 8:23
Hello again,
I do not recommend having individual end users register for
consumer keys/secrets [1] under any circumstances. So, with that out
of the way, let us focus the discussion a bit more. What can we change
about OAuth that would make this better? A complete technical [2][3]
I'm not sure that Twitter exposes any API or web service that allows
you to programatically register a new application (which you need to
do to receive the Consumer Key and Consumer Key Secret).
Even if you could, that still requires the end user to compile the
source with a modified build
I think this got lost under all the mess:
On Wed, Jul 1, 2009 at 10:15, Abraham Williams4bra...@gmail.com wrote:
A technical solution I see working is a modified PIN flow where
instead of a 6 digit PIN the user gets a 20 character token that acts
as consumer token. No harder then using PIN
Mark,
Thanks for weighing in. Much appreciated. Here are my thoughts.
I see two separate issues here: User Authentication vs. Application
Authentication.
User Authentication: Ensuring that the Twitter user is who they say
they are.
Application Authentication: Ensuring that the Application is
Matt,
Thanks for weighing in and hopefully taming this snarl. As the person
who might have posed the question originally, I figured I at least
owed a bit of constructive critique.
What can we change about OAuth that would make this better?
1) User experience - it's been echoed a
On a completely separate note, your website is stunning, did you
design it yourself? If not may I ask who were your designers.
All the best
Neil
http://www.peepwl.com
On 1 Jul 2009, at 20:22, Support wrote:
Matt,
Thanks for weighing in and hopefully taming this snarl. As the
person
On Jul 1, 2009, at 10:17 AM, DWRoelands wrote:
Mark,
Thanks for weighing in. Much appreciated. Here are my thoughts.
I see two separate issues here: User Authentication vs. Application
Authentication.
User Authentication: Ensuring that the Twitter user is who they say
they are.
This is really an excellent question.
If we're developing an open-source Twitter client, how are we supposed
to handle the consumer_key and consumer_key_secret?
On Jun 29, 7:58 pm, Support supp...@yourhead.com wrote:
2. Obfuscation of the application's registered key and secret.
Are there
The simplest solution is that every deployment of the tool will have to
register for their own OAuth credentials. This isn't ideal. I'd inquire over
at http://groups.google.com/group/oauth
On Tue, Jun 30, 2009 at 06:04, DWRoelands duane.roela...@gmail.com wrote:
This is really an excellent
Wait, the solution is that every -user- of an open-source Twitter
client would have to register for their own set of -consumer- keys?
That's not what you meant, is it?
On Jun 30, 4:39 pm, Alex Payne a...@twitter.com wrote:
The simplest solution is that every deployment of the tool will have to
That's a solution that better fits open source Twitter web services. For an
open source desktop client like Spaz it certainly doesn't work.
On Tue, Jun 30, 2009 at 16:37, DWRoelands duane.roela...@gmail.com wrote:
Wait, the solution is that every -user- of an open-source Twitter
client would
I heard the other day that in the wake of the MJ stuff, a few high
profile celebs accounts where hacked. Is this media hacking and
there were just weak passwords, or their email accounts were
compromised, or were these real live hacks where someone brute forced,
or did otherwise
Got to love these headlines:
http://mashable.com/2009/06/28/britney-spears-dead/
They clearly point the finger at twitter in the headline, but reading
on, and it is clearly a twit pic issue.
I see these all over the place. Have you considered some sort of
vetting system for sites that
Any recent celebrity-related compromises I'm aware of having been, as you
said, media 'hacking'. The last issue I'm aware of that resulted from
actually taking advantage of a security flaw in our system was the Mikeyy
worm that was going around for a weekend several months ago. We've done a
lot of
We're in contact with TwitPic's developer, and we reach out to developers
with security issues. We want to keep the barrier to entry as low as
possible on the Twitter platform, and a vetting system doesn't dovetail with
that philosophy.
On Mon, Jun 29, 2009 at 16:03, Scott Haneda
Hi Alex,I just thought I'd give you some feedback onthe"DesktopApplicationSecurity"sectionhere:http://apiwiki.twitter.com/Security-Best-Practices#DesktopApplicationSecurityBoth of the sections below seem to be subheadings under this topic:
pastedGraphic.pdf
Description: Adobe PDF document
1.
Apologies, these two sections were under the wrong heading.
On Mon, Jun 29, 2009 at 16:32, Support supp...@yourhead.com wrote:
Hi Alex,
I just thought I'd give you some feedback
on the Desktop Application Security section here:
43 matches
Mail list logo
