我一直都很好奇...在使用散列密码进行散列时哪个更好：前缀或后缀？为什么？或者它是否重要，只要你加盐？
解释一下：我们所有人（希望）现在知道我们应该在我们将数据存储在数据库中之前使用密码[ Edit: 所以你可以避免像what happened to Jeff Atwood recently这样的事情] . 通常，这是通过在将盐传递给散列算法之前将盐与密码连接来完成的 . 但是这些例子各不相同......有些例子在密码之前加盐 . 一些示例在密码后添加salt . 我甚至看到过一些尝试将盐放在中间的人 .
那么哪种方法更好，为什么呢？有没有一种方法可以减少哈希冲突的可能性？我的谷歌搜索没有找到关于这个问题的体面分析 .
Edit: 很棒的答案人们！对不起，我只能选一个答案 . :)
8 回答
前缀或后缀是无关紧要的，它只是为密码添加一些熵和长度 .
你应该考虑这三件事：
对于您存储的每个密码，盐必须不同 . （这是一个很常见的误解 . ）
使用加密安全随机数生成器 .
选择足够长的盐 . 想想生日问题 .
对于另一个问题，为什么你应该使用随机生成的盐代替用户's name (or other personal data). If you follow those suggestions, it really doesn'在你放盐的地方有一个很好的问题 .
我认为这都是语义学 . 除非针对特定的威胁模型，否则将其置于之前或之后无关紧要 .
它应该打败彩虹表的事实 .
我提到的威胁模型将是对手可以在密码附加/预先附加普通盐的彩虹表的情况 . （说国家安全局）你傻了，这是一个糟糕的猜测 .
最好假设他们有能力存储这些彩虹表，但不是说，例如，在密码中间插入奇怪的盐的表 . 在那个狭隘的案例中，我猜想穿插最好 .
就像我说的 . 这是语义 . 为每个密码选一个不同的盐，一个长盐，并在其中包含奇数字符，如符号和ASCII码：©¤¡
真正的答案，没有人似乎已经触及，是both are wrong . 如果你正在实施自己的加密，无论你认为自己在做什么都是微不足道的，你都会犯错误 .
HMAC是一种更好的方法，但即便如此，如果你已经选择了一种不适合密码散列的算法，因为它的设计速度很快 . 使用bcrypt或可能scrypt之类的东西，完全解决问题 .
哦，甚至不考虑将产生的哈希值与您的编程语言或数据库字符串比较实用程序进行比较 . 如果字符不同，那些按字符和短路比较的字符为
false. 所以现在攻击者可以使用统计方法来尝试找出哈希是什么，一次一个字符 .它应该没有任何区别 . 无论你把盐放在哪里，哈希都不会轻易猜到 . 由于故意非线性，哈希碰撞既罕见又不可预测 . 如果它对安全性产生影响，则表明散列问题，而不是腌制问题 .
如果使用加密安全散列，无论你是pre-post还是postfix都无关紧要;哈希点是源数据中的单个位更改（无论在哪里）应该产生不同的哈希 .
然而，重要的是使用长盐，使用适当的加密PRNG生成它们，并且使用每个用户的盐 . 使用站点范围的哈希 is 在数据库中存储每用户salt不是安全问题 .
首先，术语"rainbow table"一直被滥用 . "rainbow"表只是一种特殊的查找表，允许对键进行特定类型的数据压缩 . 通过交换空间计算，可以将需要1000 TB的查找表压缩一千次，以便可以将其存储在较小的驱动器驱动器上 .
你应该担心哈希到密码查找表，彩虹或其他 .
@ onebyone.livejournal.com：
对于通过输入字符串线性扫描的简单散列函数，例如简单的线性同余生成器，这是一种实际的攻击 . 但是加密安全散列函数被故意设计为具有多个循环，每个循环使用输入字符串的所有位，因此在添加盐之前计算内部状态在第一轮之后没有意义 . 例如，SHA-1有80轮 .
此外，像PBKDF这样的密码散列算法多次组合它们的散列函数（建议迭代PBKDF-2至少1000次，每次迭代应用SHA-1两次）使得这种攻击双重不切实际 .
BCrypt hash如果平台有提供者 . 我喜欢你怎么不担心创造盐，如果你愿意，你可以让它们变得更强壮 .
将盐中任意数量的字符插入密码是最不期望的情况，因此在社交方面最“安全”，但在一般情况下，只要您使用长的，每个密码唯一的密码，它实际上并不是非常重要盐的字符串 .