How to choose a salt value for ValidateAntiForgeryToken

Question

The anti-forgery token accepts a salt value. Is there any security concerns regarding choosing the salt, such as

• minimum length requirements
• cryptogra

Answer 1

General: Your salt should be a secure random, unique value greater than 128 bits (for example, /dev/urandom). This should be stored in plain text in a separate table so it can be used when verifying a hash. It should not be viewable to the client.

The general idea is that you hash the users password and the salt together, and store this value.. For example:

SHA512(password || salt)

where password is the users password, salt is the randomly generated unique value and || is concatenation.

Then when the user returns you repeat the process with the supplied password and compare this with the stored hash to verify the user's identity. If you do a quick google search you will find more information on salts and their purpose.

Edit: This is incorrect in regards to MVC anti-forgery token (refer to levi's answer), and have a read of this blog. Pretend salt is a unique form name or form id (and that it is not labelled or named salt to begin with)

Answer 2

The anti-XSRF token already contains embedded information which can uniquely identify it to a particular (user, application) pair. The 'Salt' parameter is meant to distinguish which action a particular anti-XSRF token is meant for. It isn't meant to be secret. Feel free to share it with the world. I wish we had chosen a different name for it, as the term salt is misleading. Think of it more as supplementary data. :)

We already utilize a proper cryptographic salt under the covers. For more information, see my response at runtime loading of ValidateAntiForgeryToken Salt value.

tl;dr: Don't bother with the Salt property. We're considering removing it from a future version anyway.