有很多关于盐和最佳实践的问题，但是其中大多数只是简单地回答了关于它们的非常具体的问题。我有几个问题相互补充。
假设数据库被破坏，每个用户加盐会阻止使用通用彩虹表来破解密码。必须为每个拥有唯一盐的用户生成一个单独的彩虹表，以获取他们的密码。这将是一个耗时的过程，而这正是使盐有效的原因。这对抵抗字典或蛮力攻击没有多大帮助。
这导致了一些问题：
先感谢您。
如果黑客可以访问您的数据库系统，那么您就是 fsckd。您的系统必须有权访问这两个表才能运行，因此向已经入侵系统的黑客“隐藏”一个表的可能性几乎为零。在我看来，不值得额外的复杂性。
为每个密码添加（另外）一个“nonce”并不是一个很大的帮助，但也不会真正伤害任何东西。
如果操作正确，即使 16 位盐通常也足以使密码破解变得不可行。我可能会使用 64 位或 128 位，为什么不呢？
您应该使用“好的”随机性来源，但它不需要是完美的。如果随机值对攻击者来说是可见的，那么他们可能能够找到一种方法来预测下一个随机值，但他们必须在创建密码时这样做，并且只会得到一个密码。
简而言之，您需要每个用户的盐和良好的散列函数。MD5 很糟糕，SHA-1 不再“好”。您应该使用像 bcrypt 这样的系统来强制攻击者在每个散列上花费相当多的几分之一秒。每次密码检查 0.1 秒对你来说可能没什么大不了的，但它对任何类型的暴力破解都是毁灭性的。
对于任何实施密码安全方案的人来说，这是必读的：
关于＃1，您可能会假设如果表受到损害，即使您以某种方式更好地保护它users，它们也可能会损害表。salt它只会让他们慢一点，就像减速带一样。
关于#2，硬编码的盐值通常很容易通过反编译或运行时内存检查进行逆向工程，即使有适度的代码混淆也是如此。这只会在您的应用程序被严格托管并且没有人能够掌握您编译的应用程序的情况下有助于提高安全性。
关于#3：密码哈希的最佳长度是多少？（SO 链接）- 16 很好！
关于#4，实现“更真实”的随机数并不多，具体取决于您使用的平台。例如，如果您可以权衡一些性能来生成您的种子/随机数，您可能可以更轻松地了解盐的真正随机性。
不会。正确使用盐将使攻击者破解数据库中所有密码所需的时间增加数百万倍。将盐放在另一个表中也会使攻击者获得盐所需的时间增加 30 秒。
是的。同时使用全局密钥和每个用户的盐并不是一个坏主意。
盐是或应该是加密密钥。让它长而随机。数据库大小不是问题。与任何加密密钥一样，盐可以是 128 位或 16 字节（以十六进制格式存储时为 32 字节）。
您的计算机应该具有加密性强的伪 RNG。检查您的语言的安全或加密 API。
1) 不会。攻击者可能会倾倒您系统上的所有内容并最终找到盐分（尽管这会很烦人）。
2）是的，有一个小好处 - 如果另一个系统使用与您相同的哈希方案，并且您的一些盐重叠，这将涵盖您。
3）盐的唯一要求是每个用户都是唯一的。长度与安全性无关——尽管存在广泛的混淆，但盐不是密钥。64 位随机盐永远不会重复。您还可以使用 32 位计数器，或者仅使用唯一的用户 ID。
4）盐甚至需要随机性（如果您使用随机盐）的唯一原因是确保唯一性。这是统计随机性，而不是密码随机性（猜测的可能性）。所以任何随机数库都可以。