有关哈希盐的综合信息

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

2. 为每个密码在salt中添加一个“nonce”并不是一个很好的帮助,但也不会真正伤害任何东西。

3. 即使16比特的盐通常也足以使密码破解不可行,如果正确的话。我可能会使用64或128位,为什么不呢?

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

简而言之,您需要每个用户的salt和一个好的散列函数。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

关于1,如果 users 桌子被破坏了,他们可能也会破坏 salt 表,即使你更好地保护它。这只会让他们慢一点,就像减速带一样。

关于2,硬编码的salt值通常很容易通过反编译或运行时内存检查进行反向工程,即使代码模糊程度适中。这只会在应用程序被严格托管并且没有人能够控制已编译的应用程序的情况下有助于提高安全性。

关于3: What is the optimal length for a password hash? (所以链接)-16是好的!

关于4,实现“更真实”的随机数并没有太多工作,这取决于您所使用的平台。例如,如果可以 tradeoff some performance 为了产生你的种子/随机数,你可能会比真正随机的盐更容易呼吸。

1. 不。正确使用salts会使攻击者破解数据库中所有密码所需的时间乘以数百万倍。把盐放在另一张桌子上会增加攻击者获取盐所需的30秒时间。

2. 对。同时使用全局密钥和每用户salt不是一个坏主意。

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

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

1)不。攻击者可能会将系统中的所有内容都倾倒到您的系统中,并最终找到盐(尽管这会很烦人)。

2)是的,如果另一个系统使用与您相同的散列方案,并且您的某些盐重叠,这对您有一点好处。

3)对盐的唯一要求是它对每个用户都是唯一的。长度与安全无关- 盐不是关键 尽管大家都很困惑。64位随机盐永远不会重复。您还可以使用32位计数器,如果用户ID是唯一的,也可以使用它们。

4)盐甚至需要随机性(如果使用随机盐)的唯一原因是确保唯一性。这是统计随机性,而不是密码随机性(无法猜测)。所以任何随机数库都可以。