我想知道 - 将某物的哈希用作其自身的盐有什么缺点吗？
例如 hashAlgorithm(data + hashAlgorithm(data))
这可以防止使用查找表，并且不需要在数据库中存储盐。如果攻击者无法访问源代码，他将无法获得算法，这将使暴力破解变得更加困难。
想法？（我有一种直觉，这很糟糕——但我想检查它是否真的如此，如果是，为什么。）
问问题
353 次
5 回答
6
如果攻击者无权访问源代码
这被称为“通过默默无闻的安全”，这总是被认为是不好的。一种本质上安全的方法总是更好，即使唯一的区别在于你不觉得“因为他们不知道如何”保存。有人可以而且总是会找到算法——通过仔细分析、反复试验，或者因为他们通过 SSH 连接到您的共享托管服务或其他一百种方法中的任何一种找到了源代码。
于 2010-01-08T18:49:59.397 回答
6
使用数据的散列作为数据的盐是不安全的。
salt 的目的是从其他相同的输入中产生不可预测的结果。例如，即使许多用户选择了相同的输入（例如密码），在应用了良好的盐之后，您（或攻击者）也无法分辨。
当盐是数据的函数时，攻击者可以预先计算一个查找表，因为每个密码的盐都是可预测的。
最好的盐是从用随机种子初始化的加密伪随机数生成器中选择的。如果您确实无法存储额外的盐，请考虑使用因用户而异的内容（如用户名）以及特定于应用程序的内容（如域名）。这不如随机盐好，但它没有致命的缺陷。
请记住，盐不需要保密，但它不能是被加盐数据的函数。
于 2010-01-08T19:38:51.950 回答
3
这对 hashing 没有任何改进。使用随机生成的盐。
加盐的目的是使两个按时间顺序不同的值的哈希值不同，从而破坏预先计算的查找表。
考虑：
数据=“测试”
哈希=哈希（“测试”+哈希（“测试”））
每当 data = "test" 时，哈希值将保持不变。因此，如果攻击者拥有算法（并且攻击者总是拥有算法），他们可以预先计算数据条目字典的哈希值。
于 2010-01-08T19:44:47.243 回答
3
这不是盐 - 您刚刚修改了哈希函数。攻击者无需使用原始哈希算法的查找表，只需获取您修改后的表即可；这并不妨碍使用查找表。
于 2010-01-08T19:50:08.290 回答
0
使用真正的随机数据作为盐总是更好。想象一个将用户名作为盐值的实现。这将导致“root”或“admin”等常用名称的安全性降低。
如果您不想为每个哈希创建和管理盐值，您可以使用强大的应用程序范围的盐。在大多数情况下，这将是绝对足够的，并且许多其他事情会比散列更容易受到攻击。
于 2010-01-08T19:05:48.100 回答