我想知道 - 是有什么缺点使用的东西哈希作为自身的盐？
例如的HashAlgorithm（数据的HashAlgorithm +（数据））
这防止查找表的使用，并且不需要在数据库中的盐的存储。 如果攻击者没有访问源代码，他将无法获得算法，这将使显著更难暴力破解。
思考？ （我有一个感觉：这是不好的 - 但我想检查它是否真的是，如果是的话，为什么。）
Answer 1:
如果攻击者没有访问源代码
这就是所谓的“ 通过隐藏的安全 ”，这始终被认为是坏的。 固有安全的方法是总是更好，即使唯一的不同之处在于，你不觉得保存“因为他们不知道如何”。 有人能和总能找到的算法 - 通过仔细的分析，试验和错误，或者因为他们发现通过SSH-ING您共享托管服务，或任何的一百其他方法的来源。
Answer 2:
使用数据的哈希盐的数据是不安全的。
盐的目的是从在其他方面相同的输入产生不可预测的结果。 例如，即使许多用户选择相同的输入（如密码等），应用好后加盐，你（或攻击者）将无法分辨。
当所述盐为数据的功能，攻击者可以预先计算的查找表，因为对于每个密码的盐是可预测的。
最好的盐是从与一个随机种子初始化加密的伪随机数发生器选择。 如果你真的不能存储额外的盐，可以考虑使用的东西，每个用户变化（如用户名），再加上一些特殊应用（如域名）。 这是不是一个随机盐为好，但不是致命的缺陷。
请记住，盐并不需要是秘密，但它不能被盐腌的数据的功能。
Answer 3:
这提供了只散列没有改善 。 使用随机生成的盐。
腌制的要点是让它这样两个在时间上不同的价值观散列不同，并通过这样做休息预先计算的查找表。
考虑：
数据=“测试”
散列=散列（ “测试” +散列（ “测试”））
散列将是恒定的，每当数据=“测试”。 因此，如果攻击者具有该算法（以及攻击者总是具有算法）它们可以用于数据项的字典预先计算的散列值。
Answer 4:
这不是盐 - 你刚才修改的散列函数。 除了使用查找表原来的的HashAlgorithm，攻击者可以只得到表为您修改一个; 这并不妨碍查找表的使用。
Answer 5:
它始终是更好地使用真正的随机数据作为盐。 想象一个用户名IST作为盐价值的实现。 这将导致像“根”或“admin”的通用名安全性降低。
我不想为每个哈希创建和管理一个盐值，你可以使用一个强大的应用广泛盐。 在大多数情况下，这是绝对足够和许多其他的事情会比哈希更加脆弱。
文章来源: Using a hash of data as a salt
