Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have trouble understanding nonce. I read a very good answer related to nonce by @Thomas Pornin, but it is too complicated for me as I am new to cryptography. From what I know, nonce is used to validate a form upon submission and avoid resubmission using a nonce, and to ensure the from is submitted by a valid user. Am I correct? and is this prevent CSRF implements it correctly?
For example, login form. Do I need to implement the nonce for this?

When I was reading the answer by @Thomas Pornin, few questions came up,

  1. what is the "challenge" that sent to client?
  2. Server sends challenge to client, how? In the session? hidden input in form? url?
  3. How client responds with hashed password? is client=php?
  4. what type of security this approach provides?

I am sorry I am very confused about these. I hope above information tells you the problems.

share|improve this question

2 Answers 2

up vote 12 down vote accepted

You want to use a nonce when:

  • you care deeply that a transmission not be submitted twice

AND/OR

  • you have reason to be afraid that re-transmission could occur by someone other than the authorized user, and that the ramifications of that will be bad

Transactions where money changes hands is a good sample use case - I care deeply that I not buy the same product twice without knowingly consenting. Also - any authorization case - both when a client transmits a credential to the server and when the server performs authentication checks to credential verfication services. In either case, if a third party hears the transmission, it could be repeated at a later time in imitation of the legitimate source.

The general principle is that if I am the concerned party, I can give you a suitably unique, unpredictable peice of data, and have you transmit it back to me along with proof that you are who you say you are - the proof of your identity and this suitably unique data should be melded together in such a way that a listener couldn't replicate them without having both the unique information AND your credentials.

A web form is a great context for this, as there are plenty of good cases. But it's not the only option for the implementation of the basic concepts - for example OCSP uses a nonce in certificate lookups (totally non-web - it's all in ASN.1). I don't want to add confusion, but I want to emphasize that a nonce is a security concept, not a thing that is unique to a given technology or protocol.

Taking the quesions one by one:

1.what is the "challenge" that sent to client?

Something suitably random. As usual, perfect randomness is considered impossible - but something that is unique enough that it is not repeated predictably or frequently. So as an attacker, I can't build a stockpile of useable transmissions and reuse a previously used nonce.

2.Server sends challenge to client, how? In the session? hidden input in form? url?

In a UI sense, you want to abstract it from the user, since they have no part to play in transmitting it verbatim. The way you package this is entirely related to the problem you are trying to solve. For example:

  • in an OSCP request/respose, the nonce is a field in the ASN.1 - it has an object identifier as specified in the protocol and a value. Off the top of my head, I can't remember but it may be limited to integers.

  • if you are trying to attach a nonce to a webform, a hidden value in the form input parameters is a great idea. Generally sticking this in a URL is bad idea, as URLs fit into navigation and bookmarking, and this is not a repeatable peice of data - the next time I sumbit the form with this nonce, I should be denied, so if I have bookmarked a URL with a nonce in it, I should be be very frustrated.

  • In XML transactions, I believe there's an option for including the nonce in the XMLDSIG schema - it's an element of it's own - this is often used in SOAP webservices.

    3.How client responds with hashed password? is client=php?

This points back to the point that a nonce is a concept - not an implementation. Many APIs offer a nonce as a parameter to the request initation - usually a boolean - TRUE/FALSE on providing a nonce at all.

In any case, however the client responds, there needs to be a connection between the nonce and the private credential that proves the client's identity. Hasing the nonce and the password may be an approach - but an it's not an approach I've used. But then my background is largely PKI related. If you are using assymetric keys then the typical thing would be to sign the nonce as part of the package - so the response would be a collection of information that matters for the transaction (my shopping cart order, for example), information about who I am (for example, my digital cetificate or userame), and my nonce. How I package this is a design detail for my application.

4.what type of security this approach provides?

Uniqueness.

It ensures that this exchange is happening "live" - that the response is not a canned response that could as easily be given by a malicious entity as by a server which pregenerated responses and it ensures I can't send the same transaction twice and have it work both times (replay attack).

There's a cost - the cost of computation and processing. In a high load situation, demanding re-generation and cryptographic binding for every transmission can get expensive. Not radically expensive, but for very high loads, even a little bit becomes a big deal. It also forces persistence on the requestor - the requestor has to make a nonce, send it, remember it, and compare it when the return response is provided. If there is no request/response nonce comparison, there is no value to providing the nonce in the first place. Which means there's a memory and computation cost there, as well. Also if you are custom building the transaction for a specialized purpose, it adds development time/cost. Obviously that's a one time cost - but it's still work that needs doing.

share|improve this answer
  1. A random value.

  2. Usually as a hidden value in a form.

  3. Normally, we don't want the protocol that @Thomas described. What we want is for you to use SSL and hash the password on the server side.

  4. This prevents replay and blind submission (CSRF) attacks.

If you've ever bought something online and seen a page at the end that says, "Don't refresh or resubmit this page or you'll be charged twice," then you've found somebody who should have used a nonce.

By creating a (sufficiently large) random value that is attached to the form that should be submitted, you can ensure that the form is only used once. Further, CSRF is prevented because you must first visit the form page in order to generate receive a valid nonce.

An encrypted login form probably doesn't need a nonce, but a nonce is effective in hashing a password uniquely to prevent replay over an insecure channel.

share|improve this answer
    
First, thanksX2 for the answers at optimal way to salt password and this. you solved my puzzles. Seem like only critical mission form needs nonce, am i right? Form like adding a job(row) to the "we're hiring" board is not neccessary?<br/> one more tiny question here. tweeter: posts a new tweet <- do tweeter use nonce for this? what about "Ask Question" at stackE? sorry for the questions, I wanna understand "where" to implement nonce. XD –  Tian Loon Sep 6 '12 at 9:50
    
@TianLoon See if Beth's answer covers it. That's a nice piece of work. –  Jeff Ferland Sep 6 '12 at 17:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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