腌制密码：最佳实践？
我一直很好奇......当哈希值为前缀或后缀时，哪个更好？ 为什么？ 或者它重要吗，只要你盐？
解释一下：我们现在都希望知道，在我们将它存储到数据库之前，我们应该密码。[ 编辑：所以你可以避免像最近发生的事情那样的事情]。 通常，这是通过在将密码与哈希算法传递之前串接盐和密码来完成的。 但是这些例子各不相同......有些例子在密码之前加了盐。 一些示例在密码后添加salt。 我甚至看到有些人试图把盐放在中间。
那么更好的方法是什么？为什么？ 有没有一种方法可以减少散列冲突的机会？ 我的谷歌搜索没有就这个问题做出体面的分析。
编辑：伟大的答案乡亲们！ 对不起，我只能选择一个答案。 :)
前缀或后缀是无关紧要的，只是增加了一些熵和长度的密码。
你应该考虑这三件事情：
Dave Sherohman回答了另一个问题，你为什么应该使用随机生成的盐而不是用户名（或其他个人数据）。 如果你遵循这些建议，放盐的地方确实无关紧要。
我认为这都是语义。 除了针对特定的威胁模型之外，将其放在前面或后面并不重要。
它在那里的事实应该是击败彩虹桌。
我所提到的威胁模型将是对手可以在密码后附加/附加普通盐的彩虹表的情况。 （说美国国家安全局）你猜猜他们要么附加或预先，但不是两个。 这很愚蠢，这是一个可怜的猜测。
假设他们有能力存储这些彩虹桌，但不是，比如说在密码中间散布着含有奇怪盐的桌子。 在这种狭隘的情况下，我猜想穿插会是最好的。
就像我说的。 它的语义。 每个密码选择一个不同的盐，一个长盐，并在其中包含奇数字符，如符号和ASCII码：©¤¡
真正的答案，似乎没有人涉及到，是两个都是错的。 如果你正在实施你自己的加密算法，不管你认为自己在做什么部分有多么微不足道，你都会犯错误。
HMAC是一种更好的方法，但即使如此，如果您使用的是SHA-1之类的东西，那么您已经选择了一种由于速度设计而不适合密码散列的算法。 使用bcrypt或scrypt之类的东西，完全解决你的问题。
噢，甚至不要考虑将产生的哈希与您的编程语言或数据库字符串比较实用程序进行比较。 如果字符不同，那么将字符和短路比较为false 。 因此，现在攻击者可以使用统计方法来尝试确定散列是什么，一次一个角色。