我必须承认，我对与 Web 应用程序相关的大多数高科技安全问题基本上一无所知，但我至少认为我可以问一件事，因为这是一个（希望）有具体答案的直接问题。
拿这个网站：http ://www.15seconds.com/issue/000217.htm
它表明他们将盐值存储在表中，我了解使用盐背后的原理和数学，但我想知道这一点：
为什么他们不只是使用用户名作为盐值而不是生成一个？
问问题
12595 次
3 回答
43
盐的重点是独一无二。salt旨在防止攻击成本共享，即攻击者试图以低于攻击成本两倍的成本攻击两个散列密码。
确保唯一性的一种解决方案是在足够宽的空间中生成随机盐。因此，为两个不同的密码实例获得两倍相同的盐是不可能在实践中发生的。
用户名不够唯一：
- 用户更改密码时，用户名不会更改。看到旧的散列密码和新的散列密码的攻击者可能会以低于攻击成本两倍的成本攻击两者。
- 在给定时间，用户名在系统范围内是唯一的，而不是在全球范围内。那里有很多“bob”（在 Unix 系统中，考虑“root”）。使用用户名可能允许攻击者同时攻击多个系统。
盐熵并不是很重要，除非它确保了随机生成设置中的唯一性。
于 2011-04-06T14:25:25.983 回答
30
因为用户名的熵比随机盐低，所以他们传播散列的次数比适当的盐少。
并不是说该页面上的示例无论如何都非常壮观。我总是只生成一个 GUID 并使用它。
我怀疑就现实生活中的安全性而言，这一切都在噪音中，即使是非常少量的每用户盐对安全性也有很大的影响，随着盐变得更加复杂，只有很小的改进。
于 2011-04-06T10:45:21.510 回答
1
怎么样：
Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?
那似乎
- 具有不需要存储盐的优点，因为它可以动态计算，
同时仍然具有良好的熵（基于哈希而不是明文），并且
提供与加密哈希一样长的盐，例如 128-512 位？
一个问题是，如果系统允许两个用户拥有用户名和密码（虽然电子邮件地址不会发生），但是这个方案还有其他问题吗？
于 2017-10-17T05:00:27.317 回答