关于盐和最佳实践存在很多问题,但是大多数问题只是回答有关它们的非常具体的问题.我有几个相互提问的问题.
假设数据库被泄露,每用户盐阻止使用通用彩虹表来破解密码.必须为每个拥有唯一盐的用户生成单独的彩虹表以获取其密码.这将是一个耗时的过程,这使得盐有效.这对字典或暴力攻击无济于事.
这导致了许多问题:
- 虽然盐并不意味着通过默默无闻的安全性,将盐放入单独的桌子中是不是更安全？ 这样,即使"用户"表被破坏,盐也不会.
- 拥有第二个硬编码的应用程序广泛的盐会增加大量的安全性吗？ 这样,即使数据库受到损害,实际应用程序也必须受到损害,或者盐和散列都将完全无用.
- 盐的最佳长度是多少？显然越长越好,但是随着用户数量的增加,数据库大小确实成为一个问题,那么有效盐的最小长度是多少？
- 使用第三方来源真正需要"真正的随机盐"(random.org,random.irb.hr)吗？ 我理解在某种程度上使用基于服务器时间的盐是"可猜测的",但是随机字符串的随机子字符串似乎是一种有效的盐方法.
先感谢您.