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.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 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.
Method 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)
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0