Twitter's official comment on our disabling of OAuth

[Alex Payne]

http://blog.twitter.com/2009/04/whats-deal-with-oauth.html

In short: there's a security issue with OAuth, and the major OAuth
providers are working together to patch the vulnerability before
information about the issue is publicly released. That information
will be available at http://oauth.net/ at midnight, PST.

In cooperation with this consortium of other OAuth providers
(including Yahoo!, Google, Netflix, etc.), we agreed not to disclose
the nature of the vulnerability, nor even that a vulnerability
existed, until all members of the group agreed to do so. I apologize
for what must have seemed unnecessarily tight-lipped communication
around this issue, but please understand that we and the other
companies involved are trying to mitigate the impact of this
vulnerability as much as possible.

Please also note that our OAuth support is in beta, albeit public
beta. We have not suggested to developers that they rely solely on
OAuth until our support of the standard leaves beta. I know that some
companies practice a policy of "perpetual beta", but at Twitter, we do
not. For us, "beta" really means "still in testing, not suitable for
production use".

Thanks for your patience and understanding.

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

[Dossy Shiobara]

On 4/22/09 4:27 PM, Alex Payne wrote:
> In cooperation with this consortium of other OAuth providers
> (including Yahoo!, Google, Netflix, etc.), we agreed not to disclose
> the nature of the vulnerability, nor even that a vulnerability
> existed, until all members of the group agreed to do so. I apologize
> for what must have seemed unnecessarily tight-lipped communication
> around this issue, but please understand that we and the other
> companies involved are trying to mitigate the impact of this
> vulnerability as much as possible.

Can you at least disclose whether OAuth _consumers_ who leave their
OAuth callback endpoints up are exposing themselves to risk?

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

[Alex Payne]

My understanding is, at present, that OAuth consumers are not impacted
by this issue.

--

[Dossy Shiobara]

On 4/22/09 4:37 PM, Alex Payne wrote:
> My understanding is, at present, that OAuth consumers are not impacted
> by this issue.

Perfect, thanks.

[Zac Bowling]

Everyone is using terms like "mitigate" rather then "fix", which a
clue there is probably a flaw in design that isn't accounting for the
social engineering aspect.

Maybe something that could confuse users to give their user
credentials to a third party and not the real OAuth provider when they
think they are authorizing the consuming app.

The other idea is a possible man in the middle attack. I made a proof
of concept for something like that but it was to many steps to setup
to think anyone could ever deploy it.

Interested to hear what it is.

Zac Bowling
http://twitter.com/zbowling

[bwannon]

If beta for you guys means "still in testing, not suitable for
production use", then why depreciate key features from basic auth like
source registration before you have a production ready release?

On Apr 22, 3:27 pm, Alex Payne <a...@twitter.com> wrote:
> http://blog.twitter.com/2009/04/whats-deal-with-oauth.html
>
> In short: there's a security issue with OAuth, and the major OAuth
> providers are working together to patch the vulnerability before
> information about the issue is publicly released. That information

> will be available athttp://oauth.net/at midnight, PST.

[Alex Payne]

We don't consider source registration a "key feature". It's an
incentive we provide to our developers. We wanted to encourage new
developers to look into OAuth. It won't be in beta forever, after all.

We have to balance the reality of testing a new technology in our
stack with encouraging that technology's adoption. OAuth will provide
the Twitter developer community with a number of benefits, and that's
the direction in which we want to move, even while there are kinks to
work out.

[Chris Latko]

I'm going to have to side with Alex on this one. The APIs should be
protected by OAuth and that is what should be pushed out and the basic
auth deprecated. What I don't really understand is why it has taken
until now to promote OAuth. I understand OAuth is an evolving
standard, but it has been around for quite a while.

--
Chris Latko
www.latko.org

[Dossy Shiobara]

On 4/22/09 8:23 PM, Chris Latko wrote:
> I'm going to have to side with Alex on this one. The APIs should be
> protected by OAuth and that is what should be pushed out and the basic
> auth deprecated. What I don't really understand is why it has taken
> until now to promote OAuth. I understand OAuth is an evolving
> standard, but it has been around for quite a while.

... and it's still busted, thus Twitter and other OAuth providers
_yanking_ their OAuth support until they can fix it.

At least this will raise awareness of OAuth's existance - it's finally
made it to the mainstream media.

[Abraham Williams]

While I don't like how Twitter handled this I don't think they had any choice. I feel like Twitter should have come out as soon as OAuth was disabled and said they were fixing a security issue. Security issues are however very sticky topics. Especially when megacorps like Google and Yahoo! are involved. If Twitter spills the eggs early they run the risk of being excluded from future security news.

As for Oauth. I am also dissapointed with how they handled it. OAuth is an open-spec and as such I expect an level of transparency that was not provided. This is part of the growing pains of adoption and being used in a business centric internet. I had a brief conversation with @chrismessina and @TheRazorBlade and see the reason for their decision. When OAuth services started going down I would have preferred to see a notice that a security fix was being prepared. On the plus side they did notify all known OAuth providers. OAuth is still a young spec and will learn and mature from this event.

Adoption of Twitter's OAuth will be hurt by this. Which is sad because I am tired of giving out my password. It does show how much the Twitter developer community cares though. All I heard all day was "Twitter OAuth down!" never "<insert other service here> OAuth is down!". This shows the community is thriving and active and as long as Twitter does not alienate the developers more it will continue to grow.

Abraham

--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[Julio Biason]

On Thu, Apr 23, 2009 at 10:23 AM, Chris Latko <ch...@latko.org> wrote:
> I'm going to have to side with Alex on this one. The APIs should be
> protected by OAuth and that is what should be pushed out and the basic
> auth deprecated. What I don't really understand is why it has taken
> until now to promote OAuth. I understand OAuth is an evolving
> standard, but it has been around for quite a while.

Still waiting for a good explanation of how to use OAuth in a
console-only, no-browser environment. Until then, I see that Basic
Auth should remain active.

--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason

[Doug Williams]

Julio,
We intend to keep Basic Auth available until we feel that OAuth can
successfully exit beta as a fully functioning authentication offer.
This includes support and a positive user experience for desktop
clients.

Thanks,
@dougw

--
Sent from my mobile device

Doug Williams
Twitter API Support
http://twitter.com/dougw

[Bill Robertson]

I respectfully disagree. (I would colorfully disagree, but you seem
pretty beat up right now and you don't deserve any guff) I think
developers of smaller apps see that little tag-line as a good source
of advertising, and it seems inaccessible now if you're new (right?
wrong?). You can only get it if you use OAuth, but OAuth is now
disabled?

Anyway, just my $0.02. Prioritize it like everything else you need to
do (i.e. it's the 37th #1 thing on your list.)

Good luck.

On Apr 22, 7:58 pm, Alex Payne <a...@twitter.com> wrote:
> We don't consider source registration a "key feature". It's an
> incentive we provide to our developers. We wanted to encourage new
> developers to look into OAuth. It won't be in beta forever, after all.
>
> We have to balance the reality of testing a new technology in our
> stack with encouraging that technology's adoption. OAuth will provide
> the Twitter developer community with a number of benefits, and that's
> the direction in which we want to move, even while there are kinks to
> work out.
>
>
>
> On Wed, Apr 22, 2009 at 15:37, bwannon <bwan...@gmail.com> wrote:
>
> > If beta for you guys means "still in testing, not suitable for
> > production use", then why depreciate key features from basic auth like
> > source registration before you have a production ready release?
>
> > On Apr 22, 3:27 pm, Alex Payne <a...@twitter.com> wrote:
> >>http://blog.twitter.com/2009/04/whats-deal-with-oauth.html
>
> >> In short: there's a security issue with OAuth, and the major OAuth
> >> providers are working together to patch the vulnerability before
> >> information about the issue is publicly released. That information

> >> will be available athttp://oauth.net/atmidnight, PST.

[Doug Williams]

Bill,
The majority of our developers find OAuth sufficient because they are writing a Web applications. We are pleased that the deprecation of the source parameter lowered our support load and continues to drive adoption of our preferred authentication scheme.

There are of course other cases where developers find the current implementation's beta status or browser requirement concerning. I have yet to reject a source parameter request that provides a valid argument explaining why OAuth does not meet the application's needs.

Thanks,

Doug Williams
Twitter API Support
http://twitter.com/dougw

[twitscoop]

Hi guys, is there an ETA for it to be restored ? It seems Oauth's
recommended approach is to simply add a warning notice on
authorization until this is fixed (this is what Google did). Anyways,
even with this security flow, oauth is safer than providing twitter
credentials to third parties...

Thanks!
Pierre

On Apr 23, 7:30 am, Doug Williams <d...@twitter.com> wrote:
> Bill,
> The majority of our developers find OAuth sufficient because they are
> writing a Web applications. We are pleased that the deprecation of the
> source parameter lowered our support load and continues to drive adoption of
> our preferred authentication scheme.
>
> There are of course other cases where developers find the current
> implementation's beta status or browser requirement concerning. I have yet
> to reject a source parameter request that provides a valid argument
> explaining why OAuth does not meet the application's needs.
>
> Thanks,
> Doug Williams

> Twitter API Supporthttp://twitter.com/dougw

>
> On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson

> <billrobertso...@gmail.com>wrote:

> > > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x- Hide quoted text -
>
> - Show quoted text -

[Abraham Williams]

Here is the official OAuth statement: http://oauth.net/advisories/2009-1

[mikehar]

Totally agree with Pierre. I think we all understand the security
issue. Why was twitter's approach so much more severe than other
services? Why not just a warning on login? Can Doug or Alex shed some
light on this?

wrt the ETA, can we get an update? One blog post said yesterday, the
posting on this site says today.

Also, I'm a little taken aback by the "it's beta" rationalization for
the massive disruption in service. It's one thing to mark it as public
beta, it's another thing entirely to define 'beta' belatedly as "not
suitable for production use". Does that mean we get an SLA on the non-
beta APIs?

> > > > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x-Hide quoted text -

[Ed Finkler]

That is, in fact, what "Beta" typically means: "not suitable for
production use." Overuse of the term by a few popular web apps
notwithstanding.

--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funk...@gmail.com

> > > > > Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x-Hidequoted text -

[Andrew Badera]

Corrected: "Overuse of the term by almost every web app since 2002, including GMail, notwithstanding."

[djMax]

What does this really mean these days? Clearly your desktop app is
connected to the internet in some way at some point, otherwise you
wouldn't need Twitter. So are you just saying that you never want to
have to display an HTML page? What about a web based "activation
stage" that yielded some custom mime-type that securely downloaded the
keys into your desktop app?

> Julio Biason <julio.bia...@gmail.com>
> Twitter:http://twitter.com/juliobiason

[Cameron Kaiser]

> Corrected: "Overuse of the term by almost every web app since 2002,
> including GMail, notwithstanding."

s/GMail/*.google.com/

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- The whippings shall continue until morale improves. ------------------------

[Andrew Badera]

haha, agreed.

[Matt Sanford]

Hi all,

    We had to wait for the midnight deadline before giving too many details because we're taking a slightly more active approach. The code for these changes was scheduled to go out yesterday but there was a problem with some unrelated changes and the whole thing was rolled back. I'm hoping to get it out early today as an emergency deploy. If anyone has missed it, Eran posted a good explanation [1] for people not digging the security advisory wording.

    While I'm still working to get the changes out here is what you can expect:

1. The lifetime of a Request Token is now much, much shorter. This new time limit should be long enough for a person to complete the flow, but short enough that it cuts off attacks.

    » Note this is for request tokens, not access tokens.

2. For the time being the oauth_callback parameter will be disabled for both authentication and authorization. The user will be sent to the application callback in both cases.

    » I'm working with the other OAuth implementers on a way to bring it back, and Eran mentions it a bit at the end of his post [1]. We want to make sure it works correctly before launching it so you don't end up spending time to implement something we then have to turn off.

    As for questions about the severity of Twitter's initial response I think you'll find Yahoo! [2] has done the same. From the OAuth response mails I can assure you there were others as well but since they have no public mention of it I'll let them go unmolested. It wasn't just Twitter, that was just the only place you were looking :)

Thanks;

  — Matt Sanford, "of Alex and Doug fame"

[1] - http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html

[2] - http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html

[Dossy Shiobara]

On 4/23/09 4:44 AM, twitscoop wrote:
> Anyways, even with this security flow, oauth is safer than providing
> twitter credentials to third parties...

This is _absolutely_ NOT true! An attacker can't get in the middle of
an application communicating to Twitter using HTTP Basic Auth. but they
can in an OAuth flow.

It's only "safer" in that you're not handing credentials to an otherwise
questionable third-party application. However, if you do trust a
third-party application and it uses OAuth, there is a non-zero chance
that an attacker can gain access to your Twitter account, without
needing your username or password, through the OAuth flow of your use of
the trusted application.

[Dossy Shiobara]

On 4/23/09 10:04 AM, Andrew Badera wrote:
> Corrected: "Overuse of the term by almost every web app since 2002,
> including GMail, notwithstanding."

"Web 2.0: It's Beta."

[Dossy Shiobara]

On 4/23/09 11:21 AM, Dossy Shiobara wrote:
>
> On 4/23/09 10:04 AM, Andrew Badera wrote:
>> Corrected: "Overuse of the term by almost every web app since 2002,
>> including GMail, notwithstanding."
>
> "Web 2.0: It's Beta."

(Forgive the pun, it's still early in the day ...)

[Chad Etzel]

On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobara <do...@panoptic.com> wrote:
>
> An attacker can't get in the middle of an
> application communicating to Twitter using HTTP Basic Auth.

WRONG. Anyone doing any sort of packet sniffing could easily get
user/pass combos at will. Wireless promiscuous mode + WireShark =
instant account hacking. This, of course, holds true only for http
transactions (and not https transactions), but there are a good number
of clients/apps that don't use the https endpoints.

Man in the middle attacks are certainly possible with Basic Auth as
well. They just eat the original request, steal the user/pass combo,
and do whatever they want with it.

-Chad

[Mobasoft]

Good news, the oauth_callback parameter should /always/ be set in the
application imho.
Looking forward to your "flip the switch" celebrations today.

> [1] -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses...
> [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html

[Michael Ivey]

It would be nice to be able to set multiple allowed callbacks, if this is the case, and specify which one to use in the request. I use the callback on my dev environment so I don't have to maintain two applications. (Also, the URL verification on callbacks doesn't support port numbers, but that's a secondary issue)

 -- ivey

[Matt Sanford]

Hi Michael,

    We've been discussing that in the group of people dealing with the security issue. It seems like AuthSub tried that route and found it to be very problematic. More often than not people went with open redirectors to make it easy, and therefor bypassed all security. We're working on a way to allow it to be dynamic, but make sure it is signed so we don't have to keep it this way. This involves sending it when you get the request token, and then making sure you know what you sent when you get the access token. Once we have a working version in the wild for people to try I'll give a more detailed description.

Thanks;

  – Matt Sanford / @mzsanford

      Twitter API Developer

[Andrew Badera]

What, could you hear me groaning from all the way up in Albany? ;)

[Mobasoft]

Please don't let this slow down Twitter's turning it back on.
Just let everyone set it in the application and be done with it.

If they want a different callback url, then simply create a MyApp_Test
app and put in a different application return url.

100% working sure in the hell beats 0% implemented while we try to
make it dynamic for a small percentage of applications/people.

Thanks for taking my $0.02

On Apr 23, 10:57 am, Matt Sanford <m...@twitter.com> wrote:
> Hi Michael,
>
>      We've been discussing that in the group of people dealing with  
> the security issue. It seems like AuthSub tried that route and found  
> it to be very problematic. More often than not people went with open  
> redirectors to make it easy, and therefor bypassed all security. We're  
> working on a way to allow it to be dynamic, but make sure it is signed  
> so we don't have to keep it this way. This involves sending it when  
> you get the request token, and then making sure you know what you sent  
> when you get the access token. Once we have a working version in the  
> wild for people to try I'll give a more detailed description.
>
> Thanks;
>    – Matt Sanford / @mzsanford
>        Twitter API Developer
>
> On Apr 23, 2009, at 08:47 AM, Michael Ivey wrote:
>
> > It would be nice to be able to set multiple allowed callbacks, if  
> > this is the case, and specify which one to use in the request. I use  
> > the callback on my dev environment so I don't have to maintain two  
> > applications. (Also, the URL verification on callbacks doesn't  
> > support port numbers, but that's a secondary issue)
>
> >  -- ivey
>

[Matt Sanford]

Hi there,

    It isn't slowing anything. My first change was just to disable oauth_callback, this other method is considered gravy. I'm in total agreement (as the OAuth implementer at Twitter) that it beats the hell out of 0% available.  I'm pushing with all my might to get this deployed despite anyone else's priorities. I take this all far too seriously.

Thanks;

  – Matt Sanford / @mzsanford

      Twitter API Developer

[Shannon Whitley]

Thanks, Matt! Even though it kills my latest project, I'm still in
agreement that turning oAuth back on without oauth_callback is
preferable to leaving it off.

oauth_callback is very important to me, though, so I would lobby for
bringing it back in some form as quickly as possible.

> ...
>
> read more »

[twitscoop]

Glad you stepped in, Chad, because I felt really stupid for a second.
And like I said, it's less harmful to have your oAuth session stolen
(you can just unauthorize the application) than to have your plain
twitter credentials exposed.

Anyway this is not the subject of this thread, I'm just glad we are
going to be able to play with oAuth again soon :o)

[djMax]

I understand killing oauth_callback, but I would propose that you
shouldn't kill the ability for the app to send info that will be
returned to it upon redirecting. Is this possible? For example, you
could simply pass oauth_callback back to the calling app even though
you're not going to listen to it.

> ...
>
> read more »

[Dossy Shiobara]

On 4/23/09 11:33 AM, Chad Etzel wrote:
> On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobara<do...@panoptic.com> wrote:
>> An attacker can't get in the middle of an
>> application communicating to Twitter using HTTP Basic Auth.
>
> WRONG. Anyone doing any sort of packet sniffing could easily get
> user/pass combos at will. Wireless promiscuous mode + WireShark =
> instant account hacking. This, of course, holds true only for http
> transactions (and not https transactions), but there are a good number
> of clients/apps that don't use the https endpoints.

Packet sniffing as an attack vector is significantly more difficult to
achieve than the OAuth attack is. Defend against the more likely
threats before worrying about the less likely ones.

> Man in the middle attacks are certainly possible with Basic Auth as
> well. They just eat the original request, steal the user/pass combo,
> and do whatever they want with it.

This is a standard phishing attack, and standard advice for
anti-phishing applies here.

[Chad Etzel]

On Thu, Apr 23, 2009 at 2:35 PM, Dossy Shiobara <do...@panoptic.com> wrote:
>
> On 4/23/09 11:33 AM, Chad Etzel wrote:
>>
>> On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobara<do...@panoptic.com>
>> wrote:
>>>
>>> An attacker can't get in the middle of an
>>> application communicating to Twitter using HTTP Basic Auth.
>>
>> WRONG. Anyone doing any sort of packet sniffing could easily get
>> user/pass combos at will. Wireless promiscuous mode + WireShark =
>> instant account hacking. This, of course, holds true only for http
>> transactions (and not https transactions), but there are a good number
>> of clients/apps that don't use the https endpoints.
>
> Packet sniffing as an attack vector is significantly more difficult to
> achieve than the OAuth attack is. Defend against the more likely threats
> before worrying about the less likely ones.

I wholeheartedly disagree. Sit in a tech conference room with a
laptop and sniff away at least a hundred accounts in under 5 minutes.
I'm not saying I've done it, but I'm not saying I haven't, either....

>
>> Man in the middle attacks are certainly possible with Basic Auth as
>> well. They just eat the original request, steal the user/pass combo,
>> and do whatever they want with it.
>
> This is a standard phishing attack, and standard advice for anti-phishing
> applies here.

No, phishing != man-in-the-middle. If I hack a router to intercept
all traffic headed toward twitter.com and then grok out the
credentials, this is has nothing to do with social engineering or
phishing... I've just screwed your account, and you have no idea how.

Obviously there are attack vectors with both methods, but I contend
that Basic Auth is much much much easier to attack than OAuth (even in
its current state, and even moreso when it is upgraded/patched to deal
with this new vector).

-Chad

[Mobasoft]

@mzsanford

Thanks Matt, no matter what all these other Yahoo's are saying about
you, it's appreciated!

(j/k to all you Yahoo's) ;^)

-Michael

p.s. Is OAuth back on yet? I'd hate to see it start getting the
nickname of NOAuth.

[Doug Williams]

Mobasoft,
Rest assured we will make an announcement when OAuth support is restored.

Doug Williams
Twitter API Support
http://twitter.com/dougw

[Matt Sanford]

Hi Everybody! (Dr. Nick voice)

    OAuth is once again live, and as described below the oauth_callback has been disabled. I've begun testing the replacement options for oauth_callback and will hopefully get something out soon to replace it. In the mean time successful authorization or authentication will send the user to your pre-registered callback URL.

Thanks;

  – Matt Sanford / @mzsanford

      Twitter API Developer

[Julio Biason]

On Fri, Apr 24, 2009 at 12:14 AM, djMax <djM...@gmail.com> wrote:
> What does this really mean these days?  Clearly your desktop app is
> connected to the internet in some way at some point,

Well, my *console*, *non-graphical* application is connected to the
internet, yes. Also, if that makes it clear, think about a headless
install.

>  So are you just saying that you never want to
> have to display an HTML page?

If Lynx can display, so can I. But remember that there is no
copy'n'paste or anything of sorts in there.

--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason

[Bill Robertson]

Thanks for the clarifications Doug.

[Shannon Whitley]

Thanks for all your hard work, Matt.

In one of my solutions, I am getting around the absence of the
oauth_callback by using the referrer. I know referrer is unreliable,
but I'm going with it for now. When the call comes back from the
authorize page, the referrer still contains the information that I
sent in the oauth_callback.

Additionally, if we need to setup dummy applications for testing, I'd
like to request that localhost and ports be allowed on the
registration page in the callback field.

> > [1] -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses...
> > [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html

> >>>> - Show quoted text -- Hide quoted text -

[Matt Sanford]

Hi Shannon,

    There are some concerns about localhost redirection but in the mean time I recommend changing your /etc/hosts (or equivalent) so you can intercept calls on your local machine. This should also let you do development once your project launches.

  

Thanks;

  – Matt Sanford / @mzsanford

      Twitter API Developer

[Shannon Whitley]

Thanks. That's exactly what I did. ;)

[djMax]

This is a nifty idea, I assume it's going to break when the user has
to do something other than click "Allow" right? e.g. login...

On Apr 24, 10:47 am, Shannon Whitley <shannon.whit...@gmail.com>
wrote:

[djMax]

Our OAuth-based sign-in and API-using service is up:

https://tools.povo.com/Profile/Signin/

Noticed another thing - Twitter isn't sending screen_name on the
redirect anymore.