Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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.