使用数据哈希作为盐

Question

我很想知道 - 使用某些东西的哈希是否有任何缺点？

E.g。 hashAlgorithm（data + hashAlgorithm（data））

这可以防止使用查找表，并且不需要在数据库中存储salt。如果攻击者无法访问源代码，他就无法获得算法，这会使暴力破解变得更加困难。

思考？ （我有一种直觉，认为这很糟糕 - 但我想检查它是否真的如此，如果是，为什么。）

Answer 1

  

如果攻击者无权访问源代码

这称为“security through obscurity”，它总是被认为是坏的。本质上安全的方法总是更好，即使唯一的区别在于你不觉得保存“因为他们不知道如何”。有人可以而且将永远找到算法 - 通过仔细分析，反复试验，或者因为他们通过SSH连接到您的共享托管服务或其他任何一种方法找到了源。

Answer 2

使用数据的哈希作为数据的盐不安全。

盐的目的是通过其他方面相同的输入产生不可预测的结果。例如，即使许多用户选择相同的输入（例如密码），在应用好盐之后，您（或攻击者）也无法分辨。

当salt是数据的函数时，攻击者可以预先计算查找表，因为每个密码的salt都是可预测的。

最佳盐选自用随机种子初始化的加密伪随机数发生器。如果您真的无法存储额外的盐，请考虑使用每个用户不同的内容（如用户名），以及特定于应用程序的内容（如域名）。这不如随机盐好，但它没有致命的缺陷。

请记住，盐不需要保密，但它不能成为被盐腌数据的函数。

Answer 3

这提供没有改进而只是散列。使用随机生成的盐。

腌制的目的是使两个按时间顺序排列的不同值的哈希值不同，这样做会破坏预先计算的查找表。

考虑：

  

data =“test”
  hash = hash（“test”+ hash（“test”））

只要data =“test”，哈希就会保持不变。因此，如果攻击者拥有该算法（并且攻击者总是具有该算法），则他们可以预先计算数据条目字典的哈希值。

Answer 4

这不是盐 - 你刚刚修改了哈希函数。而不是使用查找表作为原始hashAlgorithm，攻击者只需获取您修改过的表的表;这并不妨碍查找表的使用。

Answer 5

使用真正的随机数据作为盐总是更好。想象一下将用户名作为salt值的实现。这会导致“root”或“admin”等常用名称的安全性降低。

我不想为每个哈希创建和管理salt值，您可以使用强大的应用程序范围的salt。在大多数情况下，这绝对是足够的，许多其他事情比哈希更容易受到攻击。