Encryption 盐和散列，为什么不使用用户名？

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

以本网站为例：

这表明他们在表中存储了盐值，我理解使用盐背后的原理和数学，但我想知道：

---

为什么他们不直接使用用户名作为salt值，而不是生成一个值？

因为用户名的熵比随机salt低，所以它们比合适的salt散播的散列值要少

无论如何，这一页上的例子并不是非常壮观。我总是生成一个GUID并使用它

---

就现实生活中的安全性而言，我怀疑这一切都在噪音中，即使是非常少量的每用户salt也会对安全性产生很大的影响，随着salt变得更加复杂，也会有非常小的改进。

salt的要点是独特的。salt旨在防止攻击成本共享，即攻击者试图以低于攻击一个密码成本两倍的代价攻击两个哈希密码

确保唯一性的一个解决方案是在足够宽的空间中生成随机盐。因此，为两个不同的密码实例获得两次相同的salt是非常不可能的，实际上不会发生这种情况

用户名不够唯一：

• 当用户更改密码时，用户名不会更改。看到旧散列密码和新散列密码的攻击者可能会攻击这两个密码，攻击成本不到攻击成本的两倍
• 在给定的时间内，用户名在系统范围内是唯一的，而不是在全球范围内。这里有很多“Bob”（在UNIX系统中，考虑“根”）。使用用户名可能会允许攻击者同时攻击多个系统

盐熵其实并不重要，除非它能确保随机生成环境中的唯一性。

如何：

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

那似乎是

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

同时仍然具有良好的熵（基于散列而非明文），以及

提供与加密哈希（例如128-512位）一样长的salt

---

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

谢谢，这与我对这个问题的最初想法是一致的。另一个考虑因素是：使用用户名作为散列的一部分是否会使管理员在不知道用户密码或不更改密码的情况下无法更改用户的用户名？我刚刚在继承的一个系统中遇到了这个问题，该系统将电子邮件用作用户名……哈希包含一个随机的盐字符串，但由于它还包含电子邮件地址，因此导致了上述更改电子邮件的问题。@MattBrowne:很好！一个实际的想法是：如果用户试图自己更改电子邮件，通常他必须输入密码以确认更改。您可以首先验证密码（使用旧的电子邮件/用户名），然后在单个事务中更改电子邮件地址，并根据输入的密码计算新密码哈希。我并不建议使用用户名/电子邮件作为salt，只是考虑一下这个问题。但是，如果不输入密码（例如，管理员想为某人更改密码），电子邮件/用户名的更改显然仍然是不可能的。当您首次构建系统时，不可能预测所有未来的需求，其中之一可能是管理员可以更改用户名，即使一开始看起来用户可以更改自己的用户名就足够了。更改密码哈希机制是一件非常痛苦的事情，因为这意味着所有用户都必须更改密码。我经常看到关于新密码+旧密码的内容，但我不清楚为什么攻击旧密码对人们有用。我可以告诉你，我昨天使用的旧密码是“letmein”，但它今天对你没有帮助。在基于密码的加密环境中，它更有意义，例如保护Zip存档。此外，用户倾向于重复使用密码，因此旧密码通常也是将来的密码（或者是同一个人在另一个系统中使用的密码）。那么，我认为使用哈希（域+用户名+密码）之类的东西使其全局和局部唯一没有问题。不过，关于旧密码和用户名更改的争论仍然有效。这是循环的：salt用于获取“加密哈希（Passwd）”。这并不能真正回答问题，即“我们为什么不使用用户名？”，而不是“我们可以做些什么来更好地使用用户名？”。戴维斯，你能详细说明循环性吗？这里是注册+查找，似乎可以吗？
对于注册/新帐户，新用户提交他们的电子邮件和密码
系统计算Salt=Hash（Hash（Email.Hash（passwd））
系统现在可以计算该电子邮件的StoredPassword=Hash（Salt.Email.passwd）

用于登录，用户输入电子邮件和密码
系统计算Salt=Hash（Hash（Email.Hash（Passwd））
系统查找StoredPassword的电子邮件
系统将StoredPassword与Hash（Salt.Email.Passwd）进行比较
对格式设置表示歉意：（它不允许我添加换行符（它说使用“
”，但似乎这不在回复子集中），然后我的5分钟编辑时间到期。现在阅读格式/注释帮助页