Re: [twitter-dev] nonce error when doing 'generated token' OAuth

[Colin Hill]

Taylor,
   Good catch. Thanks. It was in fact a timestamp issue. The virtual
server I was using to test our twitter code hadn't been fired up in a
few weeks so before conducting yesterday's work, I updated the system
packages which included the kernel, but failed to rebuild the guest
tools which among other things handles system clock syncing to the host
server, which would have brought it in line with tock.usno.navy.mil and
without that it was way off, so that was the issue. Once corrected,
requests are succeeding once again.

Thanks all for your help.

-- Colin

On 8/17/10 10:47 AM, Taylor Singletary wrote:
> Hi Colin,
> 
> Right now we report nonce errors in a few cases -- not all of them
> having much to do with nonces unfortunately.
> 
> Check that the clock on the machines you are executing this on are
> within 5 minutes of the clock on api.twitter.com
>  -- one easy way to do this before you even
> start making OAuth-based requests is to send a HTTP HEAD request to
> http://api.twitter.com/1/help/test.xml -- you'll get a "Date" HTTP
> header, which you can consume and compare against the system clock in
> your environment, adjusting the time as necessary when creating your
> oauth_timestamp such that it's as close to as in sync with our systems
> as possible.
> 
> Additionally, you'll want to avoid oauth_nonce values with any kind of
> non-alpha-numeric characters, and generally strive to keep them globally
> unique across all possible instances of your application.
> 
> If you adjust your clock and ensure these truths about your oauth_nonce,
> and are still having issues -- we'll explore other reasons it might be
> invalid.
> 
> Taylor
> 
> On Tue, Aug 17, 2010 at 7:19 AM, Tom van der Woerdt  > wrote:
> 
> On 8/17/10 5:35 AM, Colin Hill wrote:
> > I ran into an issue when authenticating via OAuth, using the
> > token/secret pair offered for one of my apps, on the dev site
> (example)
> > http://dev.twitter.com/apps/12345/my_token
> >
> > we use the perl OAuth::Lite::Consumer module and have no difficulty
> > authenticating using the typical dance for our user facing web
> app, but
> > when migrating a cron job from basic to OAuth, using the generated
> token
> > pair as above, we now consistently get the following error:
> >
> > 401 Unauthorized
> > {"request":"/1/account/verify_credentials.json","error":"Invalid /
> used
> > nonce"}
> >
> > the passed OAuth Parameters are (consumer key redacted):
> >
> > $VAR1 = {
> >   'oauth_signature' => 'uHd1S9mCVG/dGNaHCFbl8vLHh2s=',
> >   'oauth_timestamp' => 1282000377,
> >   'oauth_consumer_key' => 'xxx',
> >   'oauth_nonce' => '95881ba3c50fa67a54fb',
> >   'oauth_version' => '1.0',
> >   'oauth_signature_method' => 'HMAC-SHA1'
> > };
> >
> > I'm reasonably sure that this all worked when I wrote and tested it
> > three weeks back, but when I went to roll it into our cron job this
> > afternoon, authentication consistently fails. I wonder if anyone
> on the
> > list has seen a similar change in behavior, and/or could offer some
> > advice as to what might generate this error. Thanks.
> >
> >   -- Colin
> 
> Hi Colin,
> 
> Quoting RFC 5849 (OAuth 1.0) :
>   A nonce is a random string, uniquely generated by the client to allow
>   the server to verify that a request has never been made before and
>   helps prevent replay attacks when requests are made over a non-secure
>   channel.  The nonce value MUST be unique across all requests with the
>   same timestamp, client credentials, and token combinations.
> 
> In other words, it has to be unique.
> 
> I'm not entirely sure, but I *think* that Twitter's implementation of
> this says that it has to be unique, but you can re-use it after 10
> minutes. That might explain why it worked before.
> 
> Tom
> 
> 

Re: [twitter-dev] nonce error when doing 'generated token' OAuth

[Tom van der Woerdt]

I'll quote some more :
   To avoid the need to retain an infinite number of nonce values for
   future checks, servers MAY choose to restrict the time period after
   which a request with an old timestamp is rejected.  Note that this
   restriction implies a level of synchronization between the client's
   and server's clocks.  Servers applying such a restriction MAY provide
   a way for the client to sync with the server's clock; alternatively,
   both systems could synchronize with a trusted time service.  Details
   of clock synchronization strategies are beyond the scope of this
   specification.

That's what I meant ;-)

And no, the nonce values are per app per user, like the specification
says :-) I personally prefer PHP's uniqid() to generate nonces.

Also, like Taylor said, check your timestamp etc. ;-)

Tom


On 8/17/10 4:59 PM, Colin Hill wrote:
> Tom,
>That was my first thought as well, but in that case, I would expect
> the request failures to be randomly distributed and relatively
> infrequent. In this case it fails every time (tested over a period of 6
> hours yesterday). I've also not encountered this issue with any of the
> other OAuth profiders we use: Google, Yahoo or LinkedIn. In the case of
> Twitter, every request  using the standard user facing auth dance
> succeeds as well. That said, I can certainly introduce an additional
> factor to enhance the uniqueness of generated nonce values to test this
> further.
> 
> With regard to Nonce uniqueness:
>"The nonce value MUST be unique across all requests with the same
>timestamp, client credentials, and token combinations."
> 
> Tom,
>Do you mean that Twitter is requiring global uniqueness within the
> window of the previous 10 minutes, rather than uniqueness over the very
> restricted subset of queries defined in the RFC? If that's the case,
> then the issue I've encountered here will only become more pervasive as
> more developers switch their implementations to OAuth over the next 13
> days. This should be interesting...
> 
> Thanks,
> Colin
> 
> On 8/17/10 10:19 AM, Tom van der Woerdt wrote:
>> On 8/17/10 5:35 AM, Colin Hill wrote:
>>> I ran into an issue when authenticating via OAuth, using the
>>> token/secret pair offered for one of my apps, on the dev site (example)
>>> http://dev.twitter.com/apps/12345/my_token
>>>
>>> we use the perl OAuth::Lite::Consumer module and have no difficulty
>>> authenticating using the typical dance for our user facing web app, but
>>> when migrating a cron job from basic to OAuth, using the generated token
>>> pair as above, we now consistently get the following error:
>>>
>>> 401 Unauthorized
>>> {"request":"/1/account/verify_credentials.json","error":"Invalid / used
>>> nonce"}
>>>
>>> the passed OAuth Parameters are (consumer key redacted):
>>>
>>> $VAR1 = {
>>>   'oauth_signature' => 'uHd1S9mCVG/dGNaHCFbl8vLHh2s=',
>>>   'oauth_timestamp' => 1282000377,
>>>   'oauth_consumer_key' => 'xxx',
>>>   'oauth_nonce' => '95881ba3c50fa67a54fb',
>>>   'oauth_version' => '1.0',
>>>   'oauth_signature_method' => 'HMAC-SHA1'
>>> };
>>>
>>> I'm reasonably sure that this all worked when I wrote and tested it
>>> three weeks back, but when I went to roll it into our cron job this
>>> afternoon, authentication consistently fails. I wonder if anyone on the
>>> list has seen a similar change in behavior, and/or could offer some
>>> advice as to what might generate this error. Thanks.
>>>
>>>   -- Colin
>>
>> Hi Colin,
>>
>> Quoting RFC 5849 (OAuth 1.0) :
>>A nonce is a random string, uniquely generated by the client to allow
>>the server to verify that a request has never been made before and
>>helps prevent replay attacks when requests are made over a non-secure
>>channel.  The nonce value MUST be unique across all requests with the
>>same timestamp, client credentials, and token combinations.
>>
>> In other words, it has to be unique.
>>
>> I'm not entirely sure, but I *think* that Twitter's implementation of
>> this says that it has to be unique, but you can re-use it after 10
>> minutes. That might explain why it worked before.
>>
>> Tom

Re: [twitter-dev] nonce error when doing 'generated token' OAuth

[Cameron Kaiser]

>That was my first thought as well, but in that case, I would expect
> the request failures to be randomly distributed and relatively
> infrequent. In this case it fails every time (tested over a period of 6
> hours yesterday). I've also not encountered this issue with any of the
> other OAuth profiders we use: Google, Yahoo or LinkedIn. In the case of
> Twitter, every request  using the standard user facing auth dance
> succeeds as well. That said, I can certainly introduce an additional
> factor to enhance the uniqueness of generated nonce values to test this
> further.

Why not just incorporate the current time into your random nonce? That's
the easiest way. If you are already doing that, the only thing I can
suggest is either using higher resolution timers or more bits of entropy.

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- /etc/motd: /earth is 98% full. please delete anyone you can. ---

Re: [twitter-dev] nonce error when doing 'generated token' OAuth

[Colin Hill]

Tom,
   That was my first thought as well, but in that case, I would expect
the request failures to be randomly distributed and relatively
infrequent. In this case it fails every time (tested over a period of 6
hours yesterday). I've also not encountered this issue with any of the
other OAuth profiders we use: Google, Yahoo or LinkedIn. In the case of
Twitter, every request  using the standard user facing auth dance
succeeds as well. That said, I can certainly introduce an additional
factor to enhance the uniqueness of generated nonce values to test this
further.

With regard to Nonce uniqueness:
   "The nonce value MUST be unique across all requests with the same
   timestamp, client credentials, and token combinations."

Tom,
   Do you mean that Twitter is requiring global uniqueness within the
window of the previous 10 minutes, rather than uniqueness over the very
restricted subset of queries defined in the RFC? If that's the case,
then the issue I've encountered here will only become more pervasive as
more developers switch their implementations to OAuth over the next 13
days. This should be interesting...

Thanks,
Colin

On 8/17/10 10:19 AM, Tom van der Woerdt wrote:
> On 8/17/10 5:35 AM, Colin Hill wrote:
>> I ran into an issue when authenticating via OAuth, using the
>> token/secret pair offered for one of my apps, on the dev site (example)
>> http://dev.twitter.com/apps/12345/my_token
>>
>> we use the perl OAuth::Lite::Consumer module and have no difficulty
>> authenticating using the typical dance for our user facing web app, but
>> when migrating a cron job from basic to OAuth, using the generated token
>> pair as above, we now consistently get the following error:
>>
>> 401 Unauthorized
>> {"request":"/1/account/verify_credentials.json","error":"Invalid / used
>> nonce"}
>>
>> the passed OAuth Parameters are (consumer key redacted):
>>
>> $VAR1 = {
>>   'oauth_signature' => 'uHd1S9mCVG/dGNaHCFbl8vLHh2s=',
>>   'oauth_timestamp' => 1282000377,
>>   'oauth_consumer_key' => 'xxx',
>>   'oauth_nonce' => '95881ba3c50fa67a54fb',
>>   'oauth_version' => '1.0',
>>   'oauth_signature_method' => 'HMAC-SHA1'
>> };
>>
>> I'm reasonably sure that this all worked when I wrote and tested it
>> three weeks back, but when I went to roll it into our cron job this
>> afternoon, authentication consistently fails. I wonder if anyone on the
>> list has seen a similar change in behavior, and/or could offer some
>> advice as to what might generate this error. Thanks.
>>
>>   -- Colin
> 
> Hi Colin,
> 
> Quoting RFC 5849 (OAuth 1.0) :
>A nonce is a random string, uniquely generated by the client to allow
>the server to verify that a request has never been made before and
>helps prevent replay attacks when requests are made over a non-secure
>channel.  The nonce value MUST be unique across all requests with the
>same timestamp, client credentials, and token combinations.
> 
> In other words, it has to be unique.
> 
> I'm not entirely sure, but I *think* that Twitter's implementation of
> this says that it has to be unique, but you can re-use it after 10
> minutes. That might explain why it worked before.
> 
> Tom

Re: [twitter-dev] nonce error when doing 'generated token' OAuth

[Taylor Singletary]

Hi Colin,

Right now we report nonce errors in a few cases -- not all of them having
much to do with nonces unfortunately.

Check that the clock on the machines you are executing this on are within 5
minutes of the clock on api.twitter.com -- one easy way to do this before
you even start making OAuth-based requests is to send a HTTP HEAD request to
http://api.twitter.com/1/help/test.xml -- you'll get a "Date" HTTP header,
which you can consume and compare against the system clock in your
environment, adjusting the time as necessary when creating your
oauth_timestamp such that it's as close to as in sync with our systems as
possible.

Additionally, you'll want to avoid oauth_nonce values with any kind of
non-alpha-numeric characters, and generally strive to keep them globally
unique across all possible instances of your application.

If you adjust your clock and ensure these truths about your oauth_nonce, and
are still having issues -- we'll explore other reasons it might be invalid.

Taylor

On Tue, Aug 17, 2010 at 7:19 AM, Tom van der Woerdt  wrote:

> On 8/17/10 5:35 AM, Colin Hill wrote:
> > I ran into an issue when authenticating via OAuth, using the
> > token/secret pair offered for one of my apps, on the dev site (example)
> > http://dev.twitter.com/apps/12345/my_token
> >
> > we use the perl OAuth::Lite::Consumer module and have no difficulty
> > authenticating using the typical dance for our user facing web app, but
> > when migrating a cron job from basic to OAuth, using the generated token
> > pair as above, we now consistently get the following error:
> >
> > 401 Unauthorized
> > {"request":"/1/account/verify_credentials.json","error":"Invalid / used
> > nonce"}
> >
> > the passed OAuth Parameters are (consumer key redacted):
> >
> > $VAR1 = {
> >   'oauth_signature' => 'uHd1S9mCVG/dGNaHCFbl8vLHh2s=',
> >   'oauth_timestamp' => 1282000377,
> >   'oauth_consumer_key' => 'xxx',
> >   'oauth_nonce' => '95881ba3c50fa67a54fb',
> >   'oauth_version' => '1.0',
> >   'oauth_signature_method' => 'HMAC-SHA1'
> > };
> >
> > I'm reasonably sure that this all worked when I wrote and tested it
> > three weeks back, but when I went to roll it into our cron job this
> > afternoon, authentication consistently fails. I wonder if anyone on the
> > list has seen a similar change in behavior, and/or could offer some
> > advice as to what might generate this error. Thanks.
> >
> >   -- Colin
>
> Hi Colin,
>
> Quoting RFC 5849 (OAuth 1.0) :
>   A nonce is a random string, uniquely generated by the client to allow
>   the server to verify that a request has never been made before and
>   helps prevent replay attacks when requests are made over a non-secure
>   channel.  The nonce value MUST be unique across all requests with the
>   same timestamp, client credentials, and token combinations.
>
> In other words, it has to be unique.
>
> I'm not entirely sure, but I *think* that Twitter's implementation of
> this says that it has to be unique, but you can re-use it after 10
> minutes. That might explain why it worked before.
>
> Tom
>

Re: [twitter-dev] nonce error when doing 'generated token' OAuth

[Tom van der Woerdt]

On 8/17/10 5:35 AM, Colin Hill wrote:
> I ran into an issue when authenticating via OAuth, using the
> token/secret pair offered for one of my apps, on the dev site (example)
> http://dev.twitter.com/apps/12345/my_token
> 
> we use the perl OAuth::Lite::Consumer module and have no difficulty
> authenticating using the typical dance for our user facing web app, but
> when migrating a cron job from basic to OAuth, using the generated token
> pair as above, we now consistently get the following error:
> 
> 401 Unauthorized
> {"request":"/1/account/verify_credentials.json","error":"Invalid / used
> nonce"}
> 
> the passed OAuth Parameters are (consumer key redacted):
> 
> $VAR1 = {
>   'oauth_signature' => 'uHd1S9mCVG/dGNaHCFbl8vLHh2s=',
>   'oauth_timestamp' => 1282000377,
>   'oauth_consumer_key' => 'xxx',
>   'oauth_nonce' => '95881ba3c50fa67a54fb',
>   'oauth_version' => '1.0',
>   'oauth_signature_method' => 'HMAC-SHA1'
> };
> 
> I'm reasonably sure that this all worked when I wrote and tested it
> three weeks back, but when I went to roll it into our cron job this
> afternoon, authentication consistently fails. I wonder if anyone on the
> list has seen a similar change in behavior, and/or could offer some
> advice as to what might generate this error. Thanks.
> 
>   -- Colin

Hi Colin,

Quoting RFC 5849 (OAuth 1.0) :
   A nonce is a random string, uniquely generated by the client to allow
   the server to verify that a request has never been made before and
   helps prevent replay attacks when requests are made over a non-secure
   channel.  The nonce value MUST be unique across all requests with the
   same timestamp, client credentials, and token combinations.

In other words, it has to be unique.

I'm not entirely sure, but I *think* that Twitter's implementation of
this says that it has to be unique, but you can re-use it after 10
minutes. That might explain why it worked before.

Tom

[twitter-dev] nonce error when doing 'generated token' OAuth

[Colin Hill]

I ran into an issue when authenticating via OAuth, using the
token/secret pair offered for one of my apps, on the dev site (example)
http://dev.twitter.com/apps/12345/my_token

we use the perl OAuth::Lite::Consumer module and have no difficulty
authenticating using the typical dance for our user facing web app, but
when migrating a cron job from basic to OAuth, using the generated token
pair as above, we now consistently get the following error:

401 Unauthorized
{"request":"/1/account/verify_credentials.json","error":"Invalid / used
nonce"}

the passed OAuth Parameters are (consumer key redacted):

$VAR1 = {
  'oauth_signature' => 'uHd1S9mCVG/dGNaHCFbl8vLHh2s=',
  'oauth_timestamp' => 1282000377,
  'oauth_consumer_key' => 'xxx',
  'oauth_nonce' => '95881ba3c50fa67a54fb',
  'oauth_version' => '1.0',
  'oauth_signature_method' => 'HMAC-SHA1'
};

I'm reasonably sure that this all worked when I wrote and tested it
three weeks back, but when I went to roll it into our cron job this
afternoon, authentication consistently fails. I wonder if anyone on the
list has seen a similar change in behavior, and/or could offer some
advice as to what might generate this error. Thanks.

  -- Colin