API is returning "invalid/used nonce"

kounch

Hi,
I'm the developer of a Smugmug client on Android.
The app accesses Smugmug via v1.2.2 of the API, and uses OAuth.

Recently, my users have been receiving this error when requesting photo or albums lists via the smugmug.images.get and smugmug.albums.get methods :

{"stat":"fail","method":"smugmug.albums.get","code":33,"message":"invalid/used nonce"}

This is a recent issue that I can't reproduce myself. The nonce is generated from a static counter which is incremented for each request, so I don't think it is used already, specially for this timestamp and signature.

Is this a common problem, any idea how the nonce can be deemed invalid ?

Thanks for your help...

devbobo

In order to prevent replay attacks, a nonce value must be unique for a given OAuth token and timestamp.

If you are receiving that error message, your app has previously used the same token, timestamp, nonce combination (they are logged to the db). Instead of using an incremented counter, perhaps MD5'ng the timestamp along with some random salt might be a better option.

Cheers,

David

kounch

I'll try the random salt, but I had the same issue with the two following solutions already :
- static incremented counter (the counter was incremented in an atomic way, so it should have been unique for the timestamp and token...)
- a hascode of the timestamp in milliseconds : this one had a small probability of being used twice

The two methods have very little probabilities of creating duplicate combinations of timestamp+nonce+token, so I'm really suspecting that the API is returning a wrong error message (and something else prevented the auth) or that something is wrong with the verification of the combination nonce+timestamp+token...

Would you be ok to take a deeper look ? the fact that this only happens in a small proportion of requests makes me think this is not an issue with the way I sign requests...

cheers

Greg

devbobo

Hey Greg,

Sorry, it's not an api bug...the error message that you are receiving is only thrown in one spot, after specifically checking if the token, timestamp, nonce combination already exists in the DB.

If it was a bug, reports of this issue would be pretty widespread, since we have quite a few apps and services using our OAuth implementation.

Cheers,

David

kounch

Thanks for confirming it.
This is very weird, but I'll have to deal with it.
I'll try the random nonce then, instead of my static counter...

kounch

Ok, found the issue : under certain conditions, my application sends a HEAD request (as opposed to GET) to know the last modified date of a feed, and see if it is worth it to download and parse the feed again. I thought this was clever, but this actually has the effect of sending twice the same request within a short amount of time (because I did not regenerate the URL) => error 33.

So all good on the API side, all my fault

cheers

Greg