I've implemented an API for one of my clients, it relies on nonces and a shared secret. The structure:

  1. Client's Site (CS) requests nonce from My App (MA), posting their username
  2. MA verifies the username is valid, then generates a nonce in response
    • The nonce is only valid for the given username and is only valid for 1 minute.
  3. CS uses the nonce to make a userful API call; the post looks like this:
    • username, nonce (from step 2), cnonce (Generated by CS), payload (Useful API call), and hash Which is a sha1 hash of the nonce, payload, shared secret, and the client nonce.
  4. MA confirms that the nonce is valid for the given username (and then invalidates the nonce for future use), and then uses the shared secret for the given username along with the nonce and provided client nonce to hash the payload and confirm the hash matches the given hash.

    If it matches, it executes the API call specified in the payload.

My question: Am I using the idea of a cnonce correctly? I'm having a hard time seeing its usefulness.

  • 3
    $\begingroup$ The construction Hash(nonce || payload || shared secret || cnonce) is a substandard Message Authentication Code; a safer option is HMAC(shared secret, (cnonce || nonce || payload) ). See the answer to this question $\endgroup$
    – fgrieu
    Nov 17, 2011 at 10:35
  • 1
    $\begingroup$ What is your goal with these nonces at all? $\endgroup$ Nov 17, 2011 at 14:21
  • $\begingroup$ @fgrieu thank you, I will switch over to that MAC convention [I have used that style before, but had forgotten about it -.- ] $\endgroup$
    – Shad
    Nov 17, 2011 at 17:47

1 Answer 1


The client nonce is there to protect the client against a replay attack. Without the client nonce, an attacker could intercept the initial request for a nonce by CS, and respond with an old nonce that the server used previously. Then, the client would use that old nonce and make an API call with it, which the attacker would again intercept, and the attacker would send back the response that the true server had actually sent when the nonce was first used. To sum up, the replay attack is about making the client interact with an old ghost of the server. The client nonce allows the client to make sure that he is talking with a "fresh and alive" server.

A client nonce would not be needed if the client had a local memory large enough to recall all previously used nonces -- the kind of memory which resists across reboots, and can store all nonces for the whole duration of the shared secret life. That's rarely practical.

  • 1
    $\begingroup$ The cnounce could and should be used as suggested in this answer; but it is not used in this way in the protocol now described in the question. For now, cnounce seems to protects only against an adversary trying to determine if shared secret has changed. $\endgroup$
    – fgrieu
    Nov 17, 2011 at 20:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.