我正在辩论使用用户名作为加盐密码的一种手段，而不是与名称一起存储随机字符串。我的理由是盐的目的是防止彩虹表，那么是什么让这实际上不如那里的另一组数据安全？
例如，
hash( md5(johnny_381@example.com), p4ss\/\/0rD)
对比
hash( md5(some_UUID_value), p4ss\/\/0rD)
我不能坚持使用用户名并简化事情是否有真正的原因？我的网络搜索得到的唯一结果是关于盐应该如何像密码的辩论，但在没有任何理由的情况下结束，我的印象是这只是为了防止像 cain-and-able 破解者这样的东西在不在一百万年的范围内与之抗衡。考虑到现实的处理限制，如果人们知道哈希，他们仍然不知道密码，我认为这没什么大不了的，他们已经进入超级计算机范围以暴力破解每个单独的哈希。
有人可以在这里启发我吗？
当用户名更改时（如果可以更改），您会遇到问题。您无法更新散列密码，因为您不存储未加盐、未散列的密码。
我认为使用用户名作为盐值没有问题。
存储密码的一种更安全的方法是为每条记录使用不同的盐值。
如果您查看 asp.net 会员提供程序的 aspnet_Membership 表，您会看到他们将密码、密码盐和用户名字段存储在几乎相同的记录中。因此，从这个角度来看，仅使用用户名作为盐值没有安全差异。
请注意，某些系统对所有密码使用单个盐值，并将其存储在配置文件中。这里安全性的唯一区别是，如果他们获得了单个盐值的访问权限，那么他们可以更轻松地构建一个彩虹表来一次破解所有密码......
但是话又说回来，如果他们可以访问加密形式的密码，那么他们可能就可以访问存储在用户表中的盐值......这可能意味着他们将有一个稍微困难的时间找出密码值。
然而，归根结底，我相信几乎所有应用程序在加密方面都失败了，因为它们只加密表面上最不重要的数据之一：密码。真正应该加密的是几乎所有其他东西。
毕竟，如果我可以访问您的数据库，我为什么要关心密码是否加密？我已经可以访问重要的东西了...
显然还有其他考虑因素在起作用，但归根结底，我不会为此过多担心，因为与其他问题相比，这是一个小问题。
If you use the username as password and there are many instances of your application, people may create rainbow tables for specific users like "admin" or "system" like it is the case with Oracle databases or with a whole list of common names like they did for WPA (CowPatty)
You better take a really random salt, it is not that difficult and it will not come back haunting you.
对于创建 HTTP 摘要身份验证的工作组来说，这种方法被认为足够安全，该身份验证使用字符串“username:realm:password”的哈希值进行操作。
我想你会觉得这个决定是秘密的。如果有人窃取了您的数据库和源代码以查看您实际上是如何实现散列的，那么他们当时登录以访问什么？显示他们已经窃取的数据库中的数据的网站？
在这种情况下，盐可以为您的用户带来一些安全优势。首先，如果窃贼有预先计算的值（彩虹表），他们必须为每个用户重新计算它们才能进行攻击；如果小偷是在寻找单个用户的密码，这不是一个大胜利。
其次，即使他们共享相同的密码，所有用户的哈希值也总是不同的，因此小偷不会免费获得任何哈希值冲突（破解一个用户获得 300 个密码）。
这两个好处有助于保护可能在多个站点上使用相同密码的用户，即使小偷碰巧获取了其他站点的数据库。
因此，虽然密码散列的盐最好保密（在您的情况下，用于盐的确切数据将是），即使它被泄露，它仍然可以提供好处。
Random salting prevents comparison of two independently-computed password hashes for the same username. Without it, it would be possible to test whether a person's password on one machine matched the one on another, or whether a password matched one that was used in the past, etc., without having to have the actual password. It would also greatly facilitate searching for criteria like the above even when the password is available (since one could search for the computed hash, rather than computing the hash separately for each old password hash value).
As to whether such prevention is a good thing or a bad thing, who knows.
I know this is an old question but for anyone searching for a solution based on this question.
If you use a derived salt (as opposed to random salt), the salt source should be strengthened by using a key derivation function like PBKDF2.
Thus if your username is "theunhandledexception" pass that through PBKDF2 for x iterations to generate a 32 bit (or whatever length salt you need) value.
Make x pseudo random (as opposed to even numbers like 1,000) and pass in a static site specific salt to the PBKDF2 and you make it highly improbable that your username salt will match any other site's username salt.