盐和哈希，为什么不使用用户名？

Question

我必须承认在与网络应用程序相关的大多数高科技安全问题上基本上无知，但有一件事我至少认为我可以问，因为这是一个直接的问题（希望）一个具体的答案。

访问此网站：http://www.15seconds.com/issue/000217.htm

它显示了他们将盐值存储在表格中的一点点，我理解使用盐背后的原理和数学，但我想知道：

• 为什么他们不只是使用用户名作为盐值而不是生成一个？

Answer 1

盐的观点是独一无二的。盐旨在防止攻击成本分担，即攻击者试图攻击两个哈希密码，其攻击成本低于攻击成本的两倍。

确保唯一性的一个解决方案是在足够宽的空间中生成随机盐。因此，为两个不同的密码实例获取两倍相同的盐是不可能的，以至于在实践中不会发生。

用户名不非常独特：

• 用户更改密码时，用户名不会更改。攻击者看到旧的哈希密码和新的哈希密码可能会以低于攻击密码成本两倍的成本攻击两者。
• 在给定时间，用户名在系统范围内是唯一的，而不是在全球范围内。那里有很多“bob”（在Unix系统中，考虑“root”）。使用用户名可能允许攻击者同时攻击多个系统。

盐熵并不重要，除非它确保随机生成设置的唯一性。

Answer 2

因为用户名的熵低于随机盐的熵，所以它们会将你的哈希值扩散到不到适当的盐值。

不是说那页上的例子非常壮观。我总是只生成一个GUID并使用它。

我怀疑现实生活中的安全问题一直存在于噪音中，即使是非常少量的每用户盐也会对安全性产生很大影响，随着盐变得越来越复杂，改进非常小。 / p>

Answer 3

怎么样：

Salt = CryptoHash( CryptoHash(SubmittedEmailOrUsername) . CryptoHash(SubmittedPasswd) ) ?

那似乎是

1. 具有不需要存储盐的优点，因为它可以动态计算，

2. 虽然仍然具有良好的熵（基于散列而不是明文），并且

3. 提供与加密哈希一样长的盐，例如128-512位？

如果系统允许两个用户拥有用户名和密码（虽然不会发生电子邮件地址），但有一个问题是，但这个方案还有其他问题吗？