Reputation: 3796
The anti-forgery token accepts a salt value. Is there any security concerns regarding choosing the salt, such as
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.
Upvotes: 16
Views: 14912
Reputation: 7212
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)
Upvotes: 0
Reputation: 32818
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.
Upvotes: 40