Security Best Practices

[Alex Payne]

I wanted to point out a blog post (http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that addresses the coming "Month of Twitter Bugs". Long story short: Twitter is in the loop, we've got security at the forefront of our daily work right now, and we're available to help if your application is identified as vulnerable or compromised.

Please check out the new wiki page (http://apiwiki.twitter.com/Security-Best-Practices) and let us know what's missing. Thanks!

--
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

[Scott Haneda]

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 nefarious acts to get in.

Some clarification on these events would help to let us know where and
how people are getting in, so we can tighten things up on our end. If
the hacks are just email accounts being gotten into, there is nothing
twitter apps need to do. If it is something else, there may be other
things we can do to keep the accounts safe.

Thanks.

On Jun 29, 2009, at 3:34 PM, Alex Payne wrote:

> I wanted to point out a blog post (http://apiblog.twitter.com/security-best-practices-for-twitter-apps
> ) that addresses the coming "Month of Twitter Bugs". Long story
> short: Twitter is in the loop, we've got security at the forefront
> of our daily work right now, and we're available to help if your
> application is identified as vulnerable or compromised.
>
> Please check out the new wiki page (http://apiwiki.twitter.com/Security-Best-Practices
> ) and let us know what's missing. Thanks!

--
Scott * If you contact me off list replace talklists@ with scott@ *

[Alex Payne]

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 security work since then, and there's more in progress.

On Mon, Jun 29, 2009 at 15:40, Scott Haneda <talk...@newgeo.com> wrote:

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 nefarious acts to get in.

Some clarification on these events would help to let us know where and how people are getting in, so we can tighten things up on our end. If the hacks are just email accounts being gotten into, there is nothing twitter apps need to do.  If it is something else, there may be other things we can do to keep the accounts safe.

Thanks.

On Jun 29, 2009, at 3:34 PM, Alex Payne wrote:

I wanted to point out a blog post (http://apiblog.twitter.com/security-best-practices-for-twitter-apps) that addresses the coming "Month of Twitter Bugs". Long story short: Twitter is in the loop, we've got security at the forefront of our daily work right now, and we're available to help if your application is identified as vulnerable or compromised.

Please check out the new wiki page (http://apiwiki.twitter.com/Security-Best-Practices) and let us know what's missing. Thanks!

--

Scott * If you contact me off list replace talklists@ with scott@ *

[Scott Haneda]

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 are asking for twitter credentials on a
3rd party site?

I can see that twitpic may not be able to use o-auth, as they want to
be able to stand alone and a image host. If there was some sort of
communication where you worked with the large sites like twit pic, it
may help. As it is now, I fell for it, I read the headline, and
thought ti was a twitter issue.

Just some food for thought.

--

[Scott Haneda]

As a separate issue, I would like to talk about privacy on twitter.
If this is the wrong place for this, let me know.

Twitter asks for my email address when I signed up. I put some pretty
stupid junk in my twitter account, and I thought I was anonymous.
Somehow, many people I associate with are finding me, putting me in a
bit of a bind.

I learned later on, by importing my personal address book into gmail,
I can login to gmail via twitter, and find all sorts of people.

This is not explained anywhere that I can tell, that my email address
can be used as a vector to locate me within twitter. With this, as
long as I use my real email address, I have no anonymity on twitter.

What are you comments on this? I know I can change my email address,
and I will shortly. Though I overlooked this, and it took me some
time to figure out how people were finding me so easily.

[Alex Payne]

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.

[Support]

Hi Alex,

I just thought I'd give you some feedback on the "Desktop Application Security" section here:

http://apiwiki.twitter.com/Security-Best-Practices#DesktopApplicationSecurity

Both of the sections below seem to be subheadings under this topic:

[Alex Payne]

Apologies, these two sections were under the wrong heading.

1.  Under this heading the sub-section of the document titled "Lack of Rate Limiting" states that we should use a "CAPTCHA" to slow down hackers.  This didn't make much sense to me as when I think of Desktop Application I think of the few that I've used:  Twitteriffic, Tweetie, and Destroy Twitter.  All of those have direct control of their UI.  Although a CAPTCHA could be used to limit scripted behaviors, it would probably be more effective just to directly limit the resource.

It's not that a CAPTCHA *couldn't* be used, it's just not something I see very often in a desktop application.

It seems to me that CAPTCHA would be more appropriate for a multi-user service than a single user desktop app -- so I was wondering if this section of the document was in the wrong area.

2.  Under the sub-section Lack of Information about Threats, it begins, "If you think there's an issue with your web application, how do you find out for sure?"  This is clearly at least a typo in the *desktop* app section, but it goes on to describe creating a "dashboard" of critical stats.  Again, this would make more sense in the context of service administrator, but I'm having trouble understanding what this would mean to a desktop application developer.

Am I misunderstanding what is meant by "Desktop Application?"  Does that mean something other than the examples I mentioned?

Thanks,

Isaiah

YourHead Software

sup...@yourhead.com

http://www.yourhead.com

On Jun 29, 2009, at 3:34 PM, Alex Payne wrote:

[Support]

Thanks for the quick change.  Nothing like real-time updates!

But I'll take you up on your querry:

We could use suggestions from desktop developers about the security issues they've run into. Developers working in sufficiently high-level languages shouldn't be dealing with buffer overflows and the usual security issues. What have you defended against? 

Off the top of my head, it seems like the two things I put the most thought into were:

1.  Storage of access keys (for OAUTH) or passwords (for basic auth).

Since an access key provides nearly as many rights as a username/password pair, it has just as much power if it is acquired by an untrusted 3rd party.  In Mac OS X the "Keychain" is the home of data that must be stored in an encrypted form and accessed through a secure API.  I'm not sure what AIR, Silverlight, or Windows devs are conquering this subject.  I imagine each platform has a set of best practices.  But it would probably be a good idea to at least mention the gravity of secure storage of these things.  Since OAuth keys are new to a lot of us, I can see someone accidentally misunderstanding this and storing them in a preference file unprotected.

2.  Obfuscation of the application's registered "key" and "secret."  Are there any best practices?  What about an open source project?

[DWRoelands]

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?

[Alex Payne]

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

[DWRoelands]

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
> register for their own OAuth credentials. This isn't ideal. I'd inquire over

> athttp://groups.google.com/group/oauth

[Alex Payne]

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.

[DWRoelands]

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 of nastiness could one do in the Twitter environment with
someone else's Consumer Key and Consumer Key Secret?

Am I making a mountain out of a molehill here? If this is not a big
deal, I'd like to hear so so I can continue working on my project as
an open source endeavor. If this is a serious security issue, then I
have to close the source for my project (and obfuscate the source).

--Duane

[Philip Plante]

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 adopted, thus
having a higher risk of being impersonated. For instance, malware
could then use the tokens from Application X to obtain authorization
from Twitter. This would require the user to authorize the
impersonator via Twitter since it is likely a new session token would
be generated. Potentially the user would likely trust this
impersonator and not think twice about authorizing it because they
will see "Application X" on Twitter.com. Once they click allow the
impersonator has control of their account. Even if the malware
doesn't spread quickly it would possibly be harder to track since it
would appear to be communications from Application X.

I am not one to cry fowl over an issue like this, just merely throwing
this out here as an idea. Anyone else have any ideas how to secure
open source oAuth apps?

[DWRoelands]

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 Consumer and the Service
Provider."

This is exactly what Twitter has done with the Consumer Secret; they
rely on it to verify the Consumer identity.

This is a thorny dilemma for open source developers. There's no way
to share the source code without compromising your application's
security, because you've got to include the Consumer Key Secret in the
source. You can obfuscate and encrypt, but a malicious actor with
access to the source code can simply "step through" the code until the
Consumer Secret is exposed in plain text.

In any event, what's done is done, and Twitter certainly isn't going
to abandon OAuth at this point. But opening the source of my Twitter
client seems to be out of the question if I want to use OAuth.

[Andrew Badera]

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 email is: [ ] bloggable [x] ask first [ ] private

[Abraham Williams]

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 malicious party.

They can not act upon user accounts without the users going through
the authorize flow. Using basic auth it is already possible to use any
source and "impersonate" another application so not much is changing
here except better security for web applications.

Abraham

--
Abraham Williams | Community Evangelist | http://web608.org
Hacker | http://abrah.am | http://twitter.com/abraham
Project | http://fireeagle.labs.poseurtech.com
This email is: [ ] blogable [x] ask first [ ] private.

[DWRoelands]

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.

[Abraham Williams]

True. But I'm pretty sure that there are more active grandfathered
sources then OAuth sources. And it takes nothing to create a new OAuth
application that has the same source as an existing OAuth application
but with only a slightly different name.

Abraham

--

[DWRoelands]

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 do.
3. As a result, open-source developers have to expose the Consumer
Secret for their application, opening their keys to potential abuse
and eventual cancellation by Twitter.

That's a problem.

What's done is done and I don't expect Twitter to abandon OAuth. But
it's an important issue that's worth talking about because it's a
security risk for developers of desktop clients.

[funkatron]

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 it could get obscured).

Not that I'm on either side of whatever this is.

On Jul 1, 9:32 am, Andrew Badera <and...@badera.us> wrote:
> 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 email is: [ ] bloggable [x] ask first [ ] private
>

[DWRoelands]

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 from analyzing the
source and being able to retrieve the Consumer Secret.

In a closed-source project, this is less of an issue. For open-source
projects, this is a pretty big problem.

Regards,
Duane

On Jul 1, 9:32 am, Andrew Badera <and...@badera.us> wrote:

[Cameron Kaiser]

> 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.

That's not workable. It has to be publicly accessible somehow.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- He hadn't a single redeeming vice. -- Oscar Wilde --------------------------

[Andrew Badera]

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 getting credit, or you're doing it for self
promotional purposes, and the conversation is moot anyhow.

"You" being any person worried about keys and open sourcing their libraries.

[Cameron Kaiser]

> 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 getting credit, or you're doing it for self
> promotional purposes, and the conversation is moot anyhow.

That's an asinine statement. So everybody who doesn't make their open
source software anonymous is a publicity whore?

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- In memory of John Banner ---------------------------------------------------

[JDG]

There's a difference between sending out an open source library and an open source APPLICATION, which requires a key be used for identification and source.

--
Internets. Serious business.

[DWRoelands]

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 seem to know what you're talking about; perhaps you have a
solution. I have written a Twitter client. This client is registered
with Twitter for OAuth. How do I share the source code without
exposing the Consumer Key Secret and still allow the end users to
authenticate?

Regards,
Duane

> >  Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com

[Cameron Kaiser]

> 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 malicious party.
>
> They can not act upon user accounts without the users going through
> the authorize flow. Using basic auth it is already possible to use any
> source and "impersonate" another application so not much is changing
> here except better security for web applications.

But the situation you state above is a bigger price to pay than if an
app is impersonated via basic auth. In basic auth, it's simply cosmetic.
In OAuth, you can certainly cause no small amount of turmoil by forcing
open source apps to push out new versions by no fault of their own. That's
not exactly an even playing field.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Man who live in glass house dress in basement. -----------------------------

[Andrew Badera]

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 week, try the veal, don't
forget to tip your waitresses and angry developers.

[Cameron Kaiser]

> 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.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Another visitor. Stay awhile. Stay forever! -- Professor Elvin Atombender --

[DWRoelands]

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 to
reveal their Consumer Key Secret.

This is a very real problem; open-source developers of desktop clients
will have to reveal their Consumer Key Secret.

Can we keep this discussion focused on the technical issues at hand,
rather than snarking about one another's motives? It's not
productive.

Regards,
Duane

> >  Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com

[Matt Sanford]

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 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 adopted, thus
> having a higher risk of being impersonated. For instance, malware
> could then use the tokens from Application X to obtain authorization
> from Twitter. This would require the user to authorize the
> impersonator via Twitter since it is likely a new session token would
> be generated. Potentially the user would likely trust this
> impersonator and not think twice about authorizing it because they
> will see "Application X" on Twitter.com. Once they click allow the
> impersonator has control of their account. Even if the malware
> doesn't spread quickly it would possibly be harder to track since it
> would appear to be communications from Application X.

One thing the above description leaves out is that not only would
the user have to approve the application, but that since it is a
desktop application they would have to type the PIN number back into
the MalewareApp. Perhaps the PIN-flow for desktop applications was not
taken into account, or maybe the wording on the PIN pages should be
stronger, but that's pretty much why we added the PIN flow.
In my mind server-side applications should not publish a consumer
key/secret. There is an assumption here that anyone savvy enough to
install your wildly successful open source server-side application can
register a key/secret … and that they probably want callbacks going to
the correct site. This is not unlike the current Twitter/OAuth
libraries, which all require you to get your own key.

[Andrew Badera]

No one's snarking, but again, interesting you would interpret it that way.

Open source all you want, each person deploying an instance will have
to get their own keys. What's so tough about that?

[Matt Sanford]

Wow, so that's what our development list (and Stallman's name) have
come to. Please don't make me close this thread. Let's keep is
friendly and focused.

— Matt

[Andrew Badera]

Amen and thank you Matt.

[Abraham Williams]

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 token.

Abraham

--

[Nancy Miracle]

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

[DWRoelands]

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

[JDG]

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 creating an open source app for people to enjoy, I'd like for people to actually know that they can use it, and the source parameter is by far the easiest way to accomplish that.

--
Internets. Serious business.

[Andrew Badera]

But that's the choice you're forced to make by OAuth, not Twitter. And
it is YOUR choice. Personally, I would probably use the conventional
mechanisms of open source: mailing lists, special interest and user
groups. Pound the pavement and promote yourself. Who said it was going
to be "easy"?

[DWRoelands]

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 client be punished by having to go through extra hoops
that users of closed-source clients don't have to endure?

Forcing users of open source Twitter clients to register their
individual installations as Twitter applications is not a viable
solution. Matt Sanford has even said so.

No one is asking for "easy". I just want open source Twitter desktop
clients to be able to compete with closed-source versions when it
comes to security. Right now, that's not possible because of
Twitter's implementation of OAuth.

Regards,
Duane

[Bruce Brown]

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

[Matt Sanford]

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]
discussion on what we could add that would make this better is
welcomed. More than welcome, it's pretty much required before we can
help.
The PIN flow was the first addition to address the inherent
insecurity of the consumer key/secret all desktop applications [3].
This stopped applications from being able to collect tokens by using
the consumer key/secret and a confidence scam (phishing like "GoodApp
needs you to re-approve us"). It sounds like there is a fervent need
for something more … what do people suggest? We're working hard on the
problem but many of you are working from the consumer standpoint and
probably have great feedback.
Please, take your time and write a well thought out reply. One-
line snarky comments, while fun to write and sometimes to read, steal
time from everyone reading the list, including all of the Twitter API
engineers. They also make the list look less inviting to new comers.

Thanks;
– Matt Sanford / @mzsanford
Twitter Dev

[1] - People installing an instance of your server-side app are not
'end users', but other developers
[2] - Not open-source hand waving.
[3] - Closed source desktop apps have the same problem. Reverse
engineering is not stopped when you don't include the source.

[DWRoelands]

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 process. Requiring Windows users to
compile source code in order to use the app is not a great solution.

Any solution to the problem should be as transparent to the user as
possible. They shouldn't be burdened with extra steps or procedures
because they chose an open source client.

[Abraham Williams]

I think this got lost under all the mess:

On Wed, Jul 1, 2009 at 10:15, Abraham Williams<4br...@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 flow but each desktop
> install would have a unique consumer sub token that could still be
> tied into the global consumer token.
>
> Abraham

--

[DWRoelands]

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 who it
says it is (i.e. the tweet is really coming from "TweetDeck" and not
some other application pretending to be TweetDeck).

User Authentication:
I understand that Basic Auth, as is, is not a secure solution.
Transmitting unencrypted credentials in the clear is never a great
idea. What about combining Basic Auth with a form of public/private
key encryption? Using PGP as an example, Twitter could publish it's
public PGP key. Applications using Basic Auth would have to encrypt
the username and password with that key and submit the encrypted
username and password as the Basic Auth credentials. Twitter decrypts
them server side and processes authentication normally. Developers
wouldn't have to include any sensitive information in their source
code, and the credentials would always be transmitted in an encrypted
fashion. PGP is a fairly robust standard, with lots of free resources
available to the development community across many languages.

Application Authentication:
This is a thornier issue that I'm not sure how to solve without having
to bundle some sort of sensitive information in the source code of an
application. However, I think the issue becomes more manageable if
User Authentication is separated from Application Authentication.

I have no doubt that many of the folks on this list have good ideas on
how to solve the second problem.

Thoughts

Regards,
Duane

[Support]

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 number of times in this board, so i won't beat the dead horse...   much...    but basic auth *is* much simpler for the user.

The reason is obvious:  oauth requires a browser. In many platforms (especially mobile) that's a painful burden.

The PIN code seems to be ignoring the elephant in the room.  It solves some problems, but at a further cost to the user experience, giving an even larger advantage to existing basic-auth apps.

You've made the pill even more effective, but so bitter that your patients can't swallow it.

Providing a scheme that does not require a browser is an obvious way to cut this gordian knot.  

2) Application authentication - if your goal is to *identify* each open source application in a *trusted* way, then I think you could be in for an uphill battle.  There are obvious technical challenges, however the larger problem is that in OSS there is no way to define "each application."  There will be many binaries for different platforms and people will fork it on github just because they can.  You cannot identify each of these variants as the same when they could be different.

And that places a burden on the user experience.  When a user grants access to "application x" -- what does that mean exactly?  Just that binary?  Just this release?  Only from a specific trusted company?  How do you explain to the user where this subtle line is drawn in a box he'll click through in less than a second?

I personally don't see an obvious solution to this problem.  It seems to be a UI challenge and a technical challenge.  In cases like that it seems prudent to question your goals and check feasibility.

Isaiah

YourHead Software

sup...@yourhead.com

http://www.yourhead.com

On Jul 1, 2009, at 9:46 AM, Matt Sanford wrote:

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] discussion on what we could add that would make this better is welcomed. More than welcome, it's pretty much required before we can help.
   The PIN flow was the first addition to address the inherent insecurity of the consumer key/secret all desktop applications [3]. This stopped applications from being able to collect tokens by using the consumer key/secret and a confidence scam (phishing like "GoodApp needs you to re-approve us"). It sounds like there is a fervent need for something more … what do people suggest? We're working hard on the problem but many of you are working from the consumer standpoint and probably have great feedback.

   Please, take your time and write a well thought out reply. One-line snarky comments, while fun to write and sometimes to read, steal time from everyone reading the list, including all of the Twitter API engineers. They also make the list look less inviting to new comers.

[Neil Ellis]

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

[Isaiah Carew]

yep, just me,

thanks,

isaiah

p.s. subject changed to protect the on-topic folks.  @isaiah for more.  ;-)

[Matt Sanford]

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.
> Application Authentication: Ensuring that the Application is who it
> says it is (i.e. the tweet is really coming from "TweetDeck" and not
> some other application pretending to be TweetDeck).
>
> User Authentication:
> I understand that Basic Auth, as is, is not a secure solution.
> Transmitting unencrypted credentials in the clear is never a great
> idea. What about combining Basic Auth with a form of public/private
> key encryption? Using PGP as an example, Twitter could publish it's
> public PGP key. Applications using Basic Auth would have to encrypt
> the username and password with that key and submit the encrypted
> username and password as the Basic Auth credentials. Twitter decrypts
> them server side and processes authentication normally. Developers
> wouldn't have to include any sensitive information in their source
> code, and the credentials would always be transmitted in an encrypted
> fashion. PGP is a fairly robust standard, with lots of free resources
> available to the development community across many languages.

Rather than breaking with the HTTP specification for Basic
authentication we offer HTTP over SSL for encrypted access. That adds
the benefits you enumerate above plus:

* Requires very little coding from developers (most libraries
support it)
* Built on an open standard
* Prevents re-using an Authentication header (even one encrypted) to
essentially act like a user.
* Bonus: Encrypts the contents so nobody else is reading your DMs on
the wire

>
> Application Authentication:
> This is a thornier issue that I'm not sure how to solve without having
> to bundle some sort of sensitive information in the source code of an
> application. However, I think the issue becomes more manageable if
> User Authentication is separated from Application Authentication.

This seems to be the crux of the issue from what I can tell. Isaiah
from youhead enumerated some of the difficulties with that, especially
for open source.

[Neil Ellis]

Yep my mistake, will contact you off line.

[Dossy Shiobara]

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 create a list of the top 10
desktop Twitter apps and their corresponding consumer key and secret.

It's all fun and games until someone discloses a secret. Then, it's
just fun ...

On 7/1/09 9:32 AM, Andrew Badera wrote:
> 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 email is: [ ] bloggable [x] ask first [ ] private
>
>
>
> On Wed, Jul 1, 2009 at 9:25 AM, DWRoelands<duane.r...@gmail.com> wrote:
>> 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 Consumer and the Service
>> Provider."
>>
>> This is exactly what Twitter has done with the Consumer Secret; they
>> rely on it to verify the Consumer identity.
>>
>> This is a thorny dilemma for open source developers. There's no way
>> to share the source code without compromising your application's
>> security, because you've got to include the Consumer Key Secret in the
>> source. You can obfuscate and encrypt, but a malicious actor with
>> access to the source code can simply "step through" the code until the
>> Consumer Secret is exposed in plain text.
>>
>> In any event, what's done is done, and Twitter certainly isn't going
>> to abandon OAuth at this point. But opening the source of my Twitter
>> client seems to be out of the question if I want to use OAuth.

>>
>>
>> On Jul 1, 8:10 am, Philip Plante<pplante....@gmail.com> 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 any open source apps use oAuth yet.

--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[Andrew Badera]

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 email is: [ ] bloggable [x] ask first [ ] private

[Duane Roelands]

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 characterization of what's required.

Furthermore, it burdens the users with additional steps (authenticating to the proxy) that users of closed-source applications don't have to do.

For my project, individual developers will simply have to register for their own tokens with Twitter.  When I package binaries for end-user distribution, I'll compile the "official" keys into the app.  It's not a great solution, but it will have to do.

[Dossy Shiobara]

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 issue
and having to scale to accomodate concurrent sessions.

The "beauty" of desktop applications is the decentralized nature, using
resources "close" to the user (as opposed to "further away" on a
server). This means scaling per user is "built in" as the user brings
their own resources.

OAuth's implicit requirement of funneling everything through a server in
order to protect a secret is a defect in the design of OAuth, one that
I've raised on the OAuth mailing lists to which I received the response
of "well, that's not a problem OAuth is trying to solve." In other
words: EPIC FAIL.

[Andrew Badera]

I wasn't thinking about downstream requests where you still need both
tokens, just token requests ... yeah, that's rough.