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.
另外，客户可以查看盐值吗？查看源代码，似乎是将salt值添加到cookie之前。
2 个解决方案
#1
40
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. :)
反XSRF令牌已经包含嵌入的信息，该信息可以唯一地将其识别为特定（用户，应用程序）对。 'Salt'参数用于区分特定反XSRF令牌的意图。这并不是秘密。随意与世界分享。我希望我们为它选择了一个不同的名称，因为盐这个词有误导性。将其视为补充数据。 :)
We already utilize a proper cryptographic salt under the covers. For more information, see my response at runtime loading of ValidateAntiForgeryToken Salt value.
我们已经在封面下使用了适当的加密盐。有关更多信息，请参阅我在运行时加载ValidateAntiForgeryToken Salt值时的响应。
tl;dr: Don't bother with the Salt property. We're considering removing it from a future version anyway.
tl; dr：不要理会Salt属性。我们正在考虑将其从未来的版本中删除。
#2
0
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.
概述：您的salt应该是一个大于128位的安全随机，唯一值（例如，/ dev / urandom）。这应该以纯文本形式存储在单独的表中，以便在验证哈希时使用它。它不应该被客户看到。
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.
其中password是用户密码，salt是随机生成的唯一值和||是串联。
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)
编辑：关于MVC反伪造令牌这是不正确的（请参阅levi的答案），并阅读此博客。假装salt是一个唯一的表单名称或表单ID（并且它没有标记或命名为salt）
#1
40
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. :)
反XSRF令牌已经包含嵌入的信息，该信息可以唯一地将其识别为特定（用户，应用程序）对。 'Salt'参数用于区分特定反XSRF令牌的意图。这并不是秘密。随意与世界分享。我希望我们为它选择了一个不同的名称，因为盐这个词有误导性。将其视为补充数据。 :)
We already utilize a proper cryptographic salt under the covers. For more information, see my response at runtime loading of ValidateAntiForgeryToken Salt value.
我们已经在封面下使用了适当的加密盐。有关更多信息，请参阅我在运行时加载ValidateAntiForgeryToken Salt值时的响应。
tl;dr: Don't bother with the Salt property. We're considering removing it from a future version anyway.
tl; dr：不要理会Salt属性。我们正在考虑将其从未来的版本中删除。
#2
0
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.
概述：您的salt应该是一个大于128位的安全随机，唯一值（例如，/ dev / urandom）。这应该以纯文本形式存储在单独的表中，以便在验证哈希时使用它。它不应该被客户看到。
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.
其中password是用户密码，salt是随机生成的唯一值和||是串联。
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)
编辑：关于MVC反伪造令牌这是不正确的（请参阅levi的答案），并阅读此博客。假装salt是一个唯一的表单名称或表单ID（并且它没有标记或命名为salt）