使用数据的哈希值作为盐
我想知道 - 使用某些东西的哈希值作为其本身的盐有什么缺点吗？
例如 hashAlgorithm(data + hashAlgorithm(data))
这可以防止使用查找表，并且不需要在数据库中存储 salt。如果攻击者无法访问源代码，他将无法获得算法，这将使暴力破解变得更加困难。
想法？ （我有一种直觉，这很糟糕 - 但我想检查一下是否真的如此，如果是，为什么。）
I was wondering - is there any disadvantages in using the hash of something as a salt of itself?
E.g. hashAlgorithm(data + hashAlgorithm(data))
This prevents the usage of lookup tables, and does not require the storage of a salt in the database. If the attacker does not have access to the source code, he would not be able to obtain the algorithm, which would make brute-forcing significantly harder.
Thoughts? (I have a gut feeling that this is bad - but I wanted to check if it really is, and if so, why.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这称为“通过模糊性实现安全性”，这总是被认为是不好的。本质上安全的方法总是更好，即使唯一的区别在于“因为他们不知道如何”让你感觉不安全。有人可以而且总会找到算法——通过仔细分析、反复试验，或者因为他们通过 SSH 连接到您的共享托管服务或一百种其他方法中的任何一种找到了源代码。
This is called "security through obscurity", which is always considered bad. An inherently safe method is always better, even if the only difference lies in the fact that you don't feel save "because they don't know how". Someone can and will always find the algorithm -- through careful analysis, trial-and-error, or because they found the source by SSH-ing to your shared hosting service, or any of a hundred other methods.
使用数据的哈希值作为数据的盐是不安全的。
盐的目的是从其他方面相同的输入中产生不可预测的结果。例如，即使许多用户选择相同的输入（例如作为密码），在应用了良好的盐之后，您（或攻击者）也将无法辨别。
当盐是数据的函数时，攻击者可以预先计算查找表，因为每个密码的盐都是可预测的。
最好的盐是从用随机种子初始化的加密伪随机数生成器中选择的。如果您确实无法存储额外的盐，请考虑使用每个用户不同的内容（例如用户名）以及特定于应用程序的内容（例如域名）。这虽然不如随机盐好，但也不是致命的缺陷。
请记住，加盐不需要保密，但它不能是加盐数据的函数。
Using a hash of the data as salt for the data is not secure.
The purpose of salt is to produce unpredictable results from inputs that are otherwise the same. For example, even if many users select the same input (as a password, for example), after applying a good salt, you (or an attacker) won't be able to tell.
When the salt is a function of the data, an attacker can pre-compute a lookup table, because the salt for every password is predictable.
The best salts are chosen from a cryptographic pseudo-random number generator initialized with a random seed. If you really cannot store an extra salt, consider using something that varies per user (like a user name), together with something application specific (like a domain name). This isn't as good as a random salt, but it isn't fatally flawed.
Remember, a salt doesn't need to be secret, but it cannot be a function of the data being salted.
这与散列相比没有任何改进。使用随机生成的盐。
加盐的目的是使两个按时间顺序不同的值的哈希值不同，从而破坏预先计算的查找表。
考虑：
每当 data = "test" 时，哈希值将保持不变。因此，如果攻击者拥有该算法（并且攻击者总是拥有该算法），他们就可以预先计算数据条目字典的哈希值。
This offers no improvement over just hashing. Use a randomly generated salt.
The point of salting is to make it so two chronologically distinct values' hashes differ, and by so doing breaks pre-calculated lookup tables.
Consider:
Hash will be constant whenever data = "test". Thus, if the attacker has the algorithm (and the attacker always has the algorithm) they can pre-calculate hash values for a dictionary of data entries.
这不是盐 - 您刚刚修改了哈希函数。攻击者可以直接获取修改后的哈希算法的表，而不是使用原始哈希算法的查找表；这并不妨碍查找表的使用。
This is not salt - you have just modified the hash function. Instead of using lookup table for the original hashAlgorithm, attacker can just get the table for your modified one; this does not prevent the usage of lookup tables.
使用真正的随机数据作为盐总是更好。想象一个将用户名作为盐值的实现。这将导致“root”或“admin”等常用名称的安全性降低。
如果您不想为每个哈希创建和管理盐值，您可以使用强大的应用程序范围的盐。在大多数情况下，这绝对足够了，而且许多其他东西比哈希值更容易受到攻击。
It is always better to use true random data as salt. Imagine an implementation where the username ist taken as salt value. This would lead to reduced security for common names like "root" or "admin".
I you don't want to create and manage a salt value for each hash, you could use a strong application wide salt. In most cases this would be absolutely sufficient and many other things would be more vulnerable than the hashes.