31 Aug, 2008

A modified Nonce implementation

Posted by Bhavin Turakhia | (6) Comments

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.