intertwingly

Nonce is a funny word that plays a serious role in a number of security implementations.  Generating a nonce is easy - a random number or the current time or a combination of the two is sufficient.

However, the key to preventing replay attacks is for the recipient to ensure that no nonce is ever reused.  On face value, this is quite a serious obligation - forever is a long time.  In any case, requiring servers to manage application state is something that is generally to be avoided whenever possible.

One way to mitigate this cost is to institute expiration policies for nonces.  This does get you into the mess of requiring clocks to be synchronized.  Luckily, effective compromises can generally be found which allow most legitimate traffic through and prevent nearly all of the rest.

Here is a simple implementation that implements expiration and uniqueness using the file system.  There are timing problems whereby a single nonce issued simultaneously on two concurrent requests could conceivably be accepted.  However, this is relatively unlikely, and my design point was to err slightly on the side of permissiveness.  Engineering trade-offs and all that.

There are two, more serious, issues with nonces as a part of a security policy.

One is that the server obligation mentioned above can be exploited in a Denial of Service (DoS) attack.  Challenge based systems that involve issuing a nonce mean that unauthenticated users can cause nonces to be generated at will.  The storage and computational requirements of uniqueness checking are clearly related to the number of outstanding nonces.  Solutions which only track nonces after all the other authentication and uniqueness checking is complete limit the DoS exposure to authenticated users.

More serious is the requirement that the server and client both have access to a common secret, generally a password.  If you have an existing application which does not retain passwords in their original form, then either a new password is required, or some process or algorithm for generating a key based on the original password needs to be published.

On the plus side, nonces allow solutions to be deployed that can be as paranoid as they want to be.  Solutions with servers which chose to outright ignore the requirement to validate the uniqueness nonces they receive are still more secure than solutions that involve passing passwords in the clear.  Furthermore, implementations of policies to check for uniqueness and acceptable expiration periods can be added later without requiring clients to change one bit.