关于哈希盐的综合信息

Question

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

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

这导致了许多问题:

虽然盐并不意味着通过默默无闻的安全性,将盐放入单独的桌子中是不是更安全？ 这样,即使"用户"表被破坏,盐也不会.
拥有第二个硬编码的应用程序广泛的盐会增加大量的安全性吗？ 这样,即使数据库受到损害,实际应用程序也必须受到损害,或者盐和散列都将完全无用.
盐的最佳长度是多少？显然越长越好,但是随着用户数量的增加,数据库大小确实成为一个问题,那么有效盐的最小长度是多少？
使用第三方来源真正需要"真正的随机盐"(random.org,random.irb.hr)吗？ 我理解在某种程度上使用基于服务器时间的盐是"可猜测的",但是随机字符串的随机子字符串似乎是一种有效的盐方法.

先感谢您.

Answer 1

如果黑客可以访问您的数据库系统,那么您就是fsckd.您的系统必须能够访问两个表才能运行,因此从已经危害系统的黑客中"隐藏"一个表的可能性几乎为零.在我看来,并不值得额外的复杂性.
为每个密码添加(另外)盐的"nonce"不是很好的帮助,但也没有真正伤害任何东西.
如果正确完成,即使16位盐通常也足以使密码破解变得不可行.我可能会使用64或128位,为什么不呢？
你应该使用"好"的随机来源,但它不需要是完美的.如果攻击者以某种方式看到随机值,那么他们可能能够找到预测下一个随机值的方法,但是在创建密码时他们必须这样做,并且只能获得一个密码.

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

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