Hi Tav,
The oauth_timestamp variable is used so we don't have to keep
track of every nonce every created since the beginning of time. By
using the timestamp we can immediately discard old reply attacks, and
with the nonce we can discard recent replay attacks. If there was no
timestamp then nonce entropy would eventually become an issue, not to
mention the speed of looking up a value in a collection of every nonce
ever created. Clock skew would have to be pretty large for this to be
an issue so I'm guessing there is something else afoot. I see that 4
people have marked issue 281 with a star and that's what I look for so
if you're not one of those that's the place to register your +1. I'll
hopefully work on the OAuth issues today if Media Temple emails calm
down.
Thanks;
— Matt Sanford
On Feb 13, 2009, at 05:50 AM, tav wrote:
Hey guys,
I'm running into arbitrary 401 Invalid OAuth Requests...
Seeing as the code works most of the time, I'm wondering whether the
``oauth_timestamp`` variable and clock skew could perhaps be the
issue?
Imagine the following scenario:
* User1 initiates Request1 (with timestamp T1) on Server1
* User2 initiates Request2 (with timestamp T2 > T1) on Server2
* Either due to clock skew or network lag, Request2 arrives at
twitter.com first
* Request2 gets served appropriately
* Request1 eventually arrives at twitter.com
* Request1 gets an Invalid OAuth Request since T1 is earlier than the
already served T2
Whoever specified the ``timestamp`` variable in the OAuth spec should
be given a slap. I'm failing to see any point in it.
An obvious fix is for an application (consumer in OAuth terminology)
to simply treat the timestamp variable as a constant, e.g.
oauth_timestamp = 219084
Doing so removes any problems caused by network lag or clock skew and,
assuming a random and large enough nonce, wouldn't cause any loss in
security or maintainability.
I already tried doing this, but unfortunately it seems that
twitter.com denies oauth_timestamp values outside of a certain
boundary?
Could we please remove that check? That is, as long as the timestamp
happens to be a static or incrementing positive integer, then it
should be accepted as being valid.
Thankfully the spec already allows for this decision to be made by the
Service Provider:
"Unless otherwise specified by the Service Provider, the timestamp
is expressed in the number of seconds since January 1, 1970
00:00:00 GMT. The timestamp value MUST be a positive integer
and MUST be equal or greater than the timestamp used in previous
requests."
I would like to propose that we take advantage of the ability to
"specify otherwise". Thank you!
And, whilst I'm at it, I'd like to +1 for more informative 401
messages: http://code.google.com/p/twitter-api/issues/detail?id=281
--
love, tav
plex:espians/tav | [email protected] | +44 (0) 7809 569 369
