如何为 ValidateAntiForgeryToken 选择盐值答案

【问题标题】：How to choose a salt value for ValidateAntiForgeryToken如何为 ValidateAntiForgeryToken 选择盐值
【发布时间】：2012-03-15 16:44:59
【问题描述】：

防伪令牌接受盐值。选择盐是否有任何安全问题，例如

另外，客户端是否可以查看盐值？查看源代码，它似乎在 cookie 中添加了盐值。

【问题讨论】：

【解决方案1】：

常规：您的 salt 应该是大于 128 位的安全随机、唯一值（例如，/dev/urandom）。这应该以纯文本形式存储在单独的表中，以便在验证哈希时使用。它不应该对客户可见。

一般的想法是你将用户密码和盐一起散列，并存储这个值。例如：

SHA512(password || salt)

其中password 是用户密码，salt 是随机生成的唯一值，|| 是串联。

然后，当用户返回时，您使用提供的密码重复该过程，并将其与存储的哈希值进行比较以验证用户的身份。如果你做一个快速的谷歌搜索，你会发现更多关于盐及其用途的信息。

编辑：这对于 MVC 防伪令牌是不正确的（请参阅 levi 的回答），并阅读此 blog。假装 salt 是唯一的表单名称或表单 ID（并且它没有被标记或命名为 salt 开头）

【讨论】：

我想知道的是，当我使用 AntiForgeryToken 时，盐值是否会发送到客户端。尽管源代码似乎在加盐，但我有限的黑客技能无法恢复它。要是能找回来，盐说傻话，那就太丢人了。
好吧，如果盐是可回收的，它会破坏它本身的目的。如果你那么担心，不要选择愚蠢的东西：P
@Prowla - 他说的是 MVC 防伪令牌的盐，而不是密码盐。这不是需要非常复杂的东西。足以阻止一次简单的攻击。正因为如此，几乎任何盐都是可以接受的。由于使用方式的性质，伪造请求的攻击窗口非常小。

【解决方案2】：

反 XSRF 令牌已经包含嵌入信息，可以将其唯一地标识为特定的（用户、应用程序）对。 'Salt' 参数旨在区分特定反 XSRF 令牌用于哪个操作。这并不意味着要保密。随时与世界分享。我希望我们为它选择一个不同的名称，因为盐这个词具有误导性。更多地将其视为补充数据。 :)

我们已经在幕后使用了适当的加密盐。有关更多信息，请参阅我在runtime loading of ValidateAntiForgeryToken Salt value 的回复。

tl;dr: 不要理会 Salt 属性。无论如何，我们正在考虑将其从未来的版本中删除。

【讨论】：