用户密码盐的最佳长度是多少？ [英] What is the optimal length for user password salt?
问题描述
任何 salt 在显示用户密码的盐渍和散列时显然将有所帮助。盐有多长时间有什么最佳做法吗？我将把盐存储在我的用户表中，所以我希望在存储大小和安全性之间进行最佳的折中。是一个随机的10个字符盐吗？或者我需要更长的时间？
这些答案大多数有点误导，表明盐和加密密钥之间的混淆。包含盐的目的是修改用于散列每个用户密码的功能，以便每个存储的密码哈希必须被单独攻击。唯一的安全要求是每个用户都是独一无二的，没有任何好处，因为它们是不可预知的或难以猜测的。
盐只需要足够长的时间，以便每个用户的盐都是唯一的。随机的64位盐不太可能重复，即使有十亿注册用户，所以这应该是罚款。一个单独重复的盐是一个相对较小的安全性问题，它允许攻击者一次搜索两个帐户，但总的来说，不会在整个数据库上加快搜索速度。即使32位盐在大多数情况下都是可以接受的，在最坏的情况下攻击者的搜索速度将达到58％。增加超过64位的盐的成本并不高，但没有安全理由这样做。
还有一个好处是也可以使用全站范围的盐每个用户盐的顶部，这将防止与其他站点上存储的密码哈希可能的冲突，并且防止使用通用彩虹表，尽管甚至32位的盐足以使彩虹表成为不切实际的攻击。 p>
甚至更简单 - 开发人员总是忽视这一点 - 如果你有唯一的用户ID或登录名，那些就像盐一样很好。如果您这样做，您应该添加一个网站范围的盐，以确保您不会与具有相同聪明想法的另一个系统的用户重叠。
Any salt at all will obviously help when salting and hashing a user's password. Are there any best practices for how long the salt should be? I'll be storing the salt in my user table, so I would like the best tradeoff between storage size and security. Is a random 10 character salt enough? Or do I need something longer?
Most of these answers are a bit misguided and demonstrate a confusion between salts and cryptographic keys. The purpose of including salts is to modify the function used to hash each user's password so that each stored password hash will have to be attacked individually. The only security requirement is that they are unique per user, there is no benefit in them being unpredictable or difficult to guess.
Salts only need to be long enough so that each user's salt will be unique. Random 64-bit salts are very unlikely to ever repeat even with a billion registered users, so this should be fine. A singly repeated salt is a relatively minor security concern, it allows an attacker to search two accounts at once but in the aggregate won't speed up the search much on the whole database. Even 32-bit salts are acceptable for most purposes, it will in the worst case speed an attacker's search by about 58%. The cost of increasing salts beyond 64 bits isn't high but there is no security reason to do so.
There is some benefit to also using a site-wide salt on top of the per-user salt, this will prevent possible collisions with password hashes stored at other sites, and prevent the use of general-purpose rainbow tables, although even 32 bits of salt is enough to make rainbow tables an impractical attack.
Even simpler-and developers always overlook this-if you have unique user IDs or login names, those serve perfectly fine as a salt. If you do this, you should add a site-wide salt to ensure you don't overlap with users of another system who had the same bright idea.
这篇关于用户密码盐的最佳长度是多少？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
