31 Aug, 2008
A modified Nonce implementation
Posted by Bhavin Turakhia
Nonce refers to random single-use (hence the name) tokens used to hash information before sending it from a client to a server to avoid having to send sensitive data in cleartext. It is typically used to send authentication information such as passwords over HTTP. In this post I describe a slightly modified implementation of using nonce.
Our goal is to make an authenticated call from the client to the server. This requires the call to contain username and password information. We wish to avoid the overhead associated with HTTPS and at the same time, ensure that the password is not sent in cleartext.
Algorithm
- Client requests the server for a nonce token and the current time of the server
- Server generates a random nonce token (servertoken) – numerical or alphanumerical and returns the same to the client with its currenttime (servercurrenttime)
- Client creates a hash of servertoken + password + servercurrenttime
- Client sends servertoken, servercurrenttime, hash to the server
- Server checks if its system time is within a 10 second range of the servercurrenttime it received. Server may need to take into account timezone differences between the client and server locations
- Server then runs the same hash algorithm using the password it has in its store, and the servertoken and servercurrenttime received from the client
- If the hash matches the hash received from the client, then the call is permitted
The above process ensures the following -
- The password is not sent in cleartext
- Anyone intercepting the communication can get the following – clienttoken, servertoken, hash. However they cannot obtain the password. Nor can they use the hash to repeat the same call after the expiry of the 10 second window. The window maybe suitably adjusted.
In another implementation the random token can be generated by the client instead of the server. The server only provides the servercurrenttime.
In another implementation the server can store the servertoken in a cache with a 10 second expiry. When the client sends the hash, the server checks if the servertoken exists. This would eliminate the need for using servercurrenttime. The servertokens could be stored in a simple memcache server.
Care should be taken that the hashing algorithm generates significantly distinct hash values for minor modifications in the token / password / currenttime.
It maybe argued that the random token is not required and that the currenttime is sufficient by itself to generate a hash. However a random salt appended with currenttime is likely more secure since it adds an element of randomness.
Why the 10 second expiry? This creates a vulnerable window for replay attacks.
I think you’re mixing up some concepts. The reason some implementations put a timestamp in the nonce is to minimise collisions of its randomness.
The server’s challenge (nonce) should be single use, thereby eliminating replay attacks, or at least preventing them to the extent that the challenge is truly random and won’t be repeated.
When the client requests a challenge, a copy of the challenge is kept in a store on the server. When the client responds the challenge is cleared from the server, preventing any replay attack since consecutive responses would not match any stored challenge.
Memcache is not a good idea for storing the nonce since it would create a race condition.
More information on this topic:
http://www.faqs.org/rfcs/rfc2831.html
http://technet.microsoft.com/en-us/library/cc780170.aspx
@cbas – this is a modified nonce implementation so let me explain / answer your queries.
firstly the timestamp is NOT only for minimizing collisions – it can be useful for many other scenarios described below.
one reason for expiry timestamps is to not have to store the nonce on the server. this reduces code complexity and enables clustering easily. for eg if you have a multiple server web cluster giving out these nonce’s you will need to have a central store for the nonce incase the subsequent auth request goes to another server in the cluster (which btw is also the reason why memcached is the perfect store for nonce’s incase you do choose to go with the server store method as opposed to the timestamp method)
additionally, there are more reasons for maintaining expiry time – which is preventing replay calls if the client call is lost. for eg, lets say a client sends a nonce request. the client’s subsequent request is logged by a middle-man. for some reason the client call never reaches the server. now the server continues to store the nonce. subsequently the man-in-the-middle can send in this call a few minutes later with modified params. to avoid this – the server maintains an expiry – which means that the nonce can only be used within a time window. this once again makes memcached an excellent choice for the nonce store since memcached has a content-expiry field that can be set on any content and it will itself take care of the expiry
lastly offcourse even if there is no man-in-the-middle, we do not want the server caching thousands of nonce’s forever if any rogue or broken clients request nonce’s but never make the subsequent auth call
Hey Bhavin – one assumption in this scheme is that the server has knowledge of the actual password. Its fine to make that assumption, but it does mean that this scheme cannot be used in a vast majority of cases. Most (good) authentication systems don’t store the plaintext password on the server, but rather, a one-way hash of it (possibly with some salt).
@shreyas: actually this is something I am aware of. Most servers will not store a plaintext password. In this case it is assumed that the client will hash the plaintext password and then rehash the resulting hash with the nonce. In most cases one-way hashes on the server do not need salt. They are only meant to ensure someone looking at the hash cannot reverse engineer the password
I received my ugg ultra short today, very
impressed. They are like sort of a massive slipper, soft, easy to
wear and light.
GREAT ugg ultra tall THANK YOU QUICK SERVICE.