关于哈希盐的综合信息

Question

关于盐和最佳实践存在很多问题，但是大多数问题只是回答有关它们的非常具体的问题。我有几个相互提问的问题。

假设某个数据库受到威胁，每用户盐会阻止使用通用彩虹表来破解密码。必须为每个拥有唯一盐的用户生成单独的彩虹表以获取其密码。这将是一个耗时的过程，这使得盐有效。这对字典或暴力攻击无济于事。

这导致了许多问题：

1. 虽然盐不是security through obscurity，但将盐放在单独的桌子上会不会更安全？ 这样即使'用户'表被破坏，盐也不会。
2. 使用第二个硬编码的应用程序范围的盐会增加大量的安全性吗？ 这样即使数据库受到损害，实际的应用程序也必须受到损害，否则盐和哈希都将完全没用。
3. 盐的最佳长度是多少？显然越长越好，但是随着用户数量的增加，数据库大小确实成为一个问题，那么有效盐的最小长度是多少？
4. 使用第三方来源真正需要“真正的随机盐”（random.org，random.irb.hr）吗？ 我理解在某种程度上使用基于服务器时间的盐是“可猜测的”，但是随机字符串的随机字符串似乎是一种有效的盐方法。

提前谢谢。

Answer 1

1. 如果黑客可以访问您的数据库系统，那么您就是fsckd。您的系统必须能够访问两个表才能运行，因此从已经危害系统的黑客中“隐藏”一个表的可能性几乎为零。在我看来，不值得额外的复杂性。

2. 为每个密码添加一个“nonce”（另外）加入盐并不是一个很好的帮助，但也没有真正伤害任何东西。

3. 如果正确完成，即使16位盐通常也足以使密码破解变得不可行。我可能会使用64位或128位，为什么不呢？

4. 你应该使用“好”的随机来源，但它不需要是完美的。如果攻击者以某种方式看到随机值，那么他们可能能够找到预测下一个随机值的方法，但是在创建密码时它们必须这样做，并且只能获得一个密码。 / p>

简而言之，您需要每用户盐和良好的散列函数。 MD5非常糟糕，SHA-1不再“好”。您应该使用像bcrypt这样的系统来强制攻击者在每个哈希上花费相当多的时间。每次密码检查0.1秒对你来说可能没什么大不了的，但它对任何一种暴力破解都是毁灭性的。

对于实施密码安全方案的任何人来说，这是必读的：

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Answer 2

关于＃1，您可以假设如果users表被泄露，它们可能也会危及salt表，即使您以某种方式更好地保护它。它只会减慢它们的速度，就像速度碰撞一样。

关于＃2，即使使用适量的代码混淆，硬编码的salt值通常也可以通过反编译或运行时内存检查轻松进行逆向工程。这只会在严格托管您的应用程序并且没有人能够获取您编译的应用程序的情况下帮助提高安全性。

关于＃3：What is the optimal length for a password hash?（SO链接） - 16很好！

关于＃4，根据您正在使用的平台，实施“更真实”的随机数并不是更多的工作。例如，如果您可以tradeoff some performance生成种子/随机数，那么您可以更轻松地了解盐的真实随机性。

Answer 3

1. 没有。正确使用salt会使攻击者将数据库中的所有密码破解数百万倍所需的时间成倍增加。将盐放入另一个表中会使攻击者获得盐的时间增加30秒。

2. 是。使用全局密钥和每用户盐都不是一个坏主意。

3. 盐是或应该是加密密钥。让它长而随机。数据库大小不是问题。与任何加密密钥一样，salt可以是128位或16字节（以十六进制格式存储时为32字节）。

4. 您的计算机应具有加密强的伪RNG。检查您的语言的安全性或加密API。

Answer 4

1）否。攻击者可能会将所有内容转储到您的系统上并最终找到盐（尽管这会很烦人）。

2）是的，有一个小的好处 - 如果另一个系统使用与您相同的哈希方案，并且您的一些盐重叠，这将涵盖您。

3）盐的唯一要求是每个用户都是唯一的。尽管存在广泛的混淆，但长度与安全无关 - 盐不是关键。 64位随机盐永远不会重复。您也可以使用32位计数器，或者只使用用户ID（如果用户ID是唯一的）。

4）盐甚至需要随机性（如果你使用随机盐）的唯一原因是确保独特性。这是统计随机性，而不是加密随机性（猜测的不可能性）。所以任何随机数字库都可以。