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
• cryptographically strong
• mix of alpha-numeric and other characters (like that of passwords)

Also, is the salt value viewable by the client? Looking at the source code, it seems to be prepending the salt value to the cookie.

Lucais

Answer 1

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.

Rick

Answer 2

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)

Serum

What I want to know is whether the salt value gets sent to the client when I use AntiForgeryToken. Although the source code seems to be prepending the salt, my limited hacking skill couldn't recover it. It would be quite embarrassing if it could be recovered and the salt says something stupid. – Lucais

Well if the salt is recoverable it would defeat the purpose of itself.. Also if you are that concerned, don't pick something stupid :P – Serum

@Prowla - He's talking about the salt for an MVC anti-forgery token, not a password salt. This isn't something that needs a huge sophistication. Just enough to thwart a simple attack. Because of that, pretty much any salt is going to be acceptable. The window of attack is very small with forged requests due to the nature of how they can be utilized. – Contumelious