need help understanding nonce
The purpose of a nonce is to make each request unique so that an attacker can't replay a request in a different context. It doesn't matter if the attacker gets the nonce: in fact the point is that because the data includes a nonce, it won't be useful to the attacker.
ADDED:
A nonce is randomly generated by the party that introduces it into the conversation. It's crucial that an attacker cannot influence the choice of the nonce, and sometimes that the attacker can't predict that choice. It's quite typical that each party generates at least once nonce in a run of a distributed protocol.
There are protocols where a nonce is kept secret. A session key can be both a nonce (i.e., chosen randomly by one participant) and a secret (i.e. not transmitted directly over the wire). In fact, in a well-designed protocol, a session key is often derived from two nonces, once coming from each party. But being secret is not a defining property of nonces.
Let's take the authentication protocol on the wikipedia page as an example. The normal sequence of operations is:
- The client initiates a connection to the server.
- The server generates and sends a nonce
snonceback to the client. - The client generates another nonce
cnonce, and sends it plus a hash of its credentials, the server nonce and the client nonce (hash(snonce + cnonce + password)) to the server. - The server validates the hash and accepts or declines the logon.
Suppose Mallory (an attacker) can observe all traffic and send her own messages. If she gets hold of the nonce after step 2, she can send her own credentials to the server. This might help her cause a denial of service, but she can do that anyway if she can inject traffic. Without the client's credentials, she can't impersonate the client.
Suppose Mallory gets hold of the packet sent by the client in step 3. Since the credentials and the nonce are hashed, she can't modify the packet, she can only send it again as a whole. Again, depending on how the server implements the protocol, she might be able to cause a denial of service, but no more. (Note that this protocol requires that the server keeps track of which nonce is associated with which client and responds to that client in step 4.) The hashing operation in step 3 is what keeps Mallory from obtaining data she mustn't get (the client's password).
To see why the server nonce is there, suppose it was missing. Then Mallory would be able to obtain a packet containing hash(cnonce + passoword), and she could resend it later in a separate connection and thereby impersonate the client.
The client nonce serves a similar purpose, although this is not apparent in the simplified protocol described here; in a full protocol, the “token” would include a hash of data containing this nonce, and it would participate in preventing Mallory from impersonating the server.
The client nonce also serves to prevent a password guessing attack. Suppose Mallory intercepts the server's response at step 2 and substitutes her own server nonce. If the client replied with hash(snonce + password), this would make it easier for Mallory to run a mass password guessing attack: she could precompute hash(snonce + x) for many “easily guessable” passwords x, and run her attack on many clients in the hope that one has a weak password. Here the client nonce acts as a salt for the hashed password.
The client nonce also contributes to protect the client from a badly implemented server. Suppose the server did not generate a random nonce but instead a constant that Mallory could easily find by observing traffic. Then Mallory could perform the guessing attack described in the previous paragraph passively. Thus the client nonce gives the client additional protection even if the server doesn't implement the protocol correctly. Similarly, the server nonce gives the server some protection against a client that didn't generate its nonce properly, again by requiring Mallory to attack the client actively if she wants to run a password guessing attack. This is a common scenario: each party's nonce offers that party some protection even if another party deviates from the protocol.
If the hacker got the nonce and uses it before the user does, the hacker win. The idea behinde the nonce is that in some situations, it's hard for the hacker to steal a nonce (Typically XSRF, the nonce is protected by the same-origin-policy). So the nonce can't protect your user if the hacker can steal a valid nonce.