Salting：使用用户名是否合理？
我正在讨论使用用户名作为对密码加盐的方法，而不是将随机字符串与名称一起存储。我的理由是盐的目的是防止彩虹表，那么是什么使得它实际上比其中的另一组数据更不安全呢？
例如，
hash( md5([电子邮件受保护]), p4ss\/\/0rD)
与
hash( md5(some_UUID_value), p4ss\/\/0rD)
是否有真正的原因我不能只坚持使用用户名并简化事物？我的网络搜索结果唯一的结果是关于盐应该如何像密码一样的争论，但结束时没有任何理由，我的印象是这只是为了防止类似的事情该隐能破解者可以在不超过一百万年的范围内与它对抗。考虑到现实的处理局限性，如果人们知道哈希值，但他们仍然不知道密码，并且他们已经进入超级计算机范围来暴力破解每个单独的哈希值，我认为这没什么大不了的。
有人可以在这里启发我吗？
I am debating using user-names as a means to salt passwords, instead of storing a random string along with the names. My justification is that the purpose of the salt is to prevent rainbow tables, so what makes this realistically less secure than another set of data in there?
For example,
hash( md5([email protected]), p4ss\/\/0rD)
vs
hash( md5(some_UUID_value), p4ss\/\/0rD)
Is there a real reason I couldn't just stick with the user name and simplify things? The only thing my web searching resulted was debates as to how a salt should be like a password, but ended without any reasoning behind it, where I'm under the impression this is just to prevent something like a cain-and-able cracker to run against it without being in the range of a million years. Thinking about processing limitations of reality, I don't believe this is a big deal if people know the hash, they still don't know the password, and they've moved into the super-computer range to brute force each individual hash.
Could someone please enlighten me here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
当用户名更改时（如果可以更改），您会遇到问题。您无法更新哈希密码，因为您不存储未加盐、未哈希的密码。
You'll run into problems, when the username changes (if it can be changed). There's no way you can update the hashed password, because you don't store the unsalted, unhashed password.
我认为使用用户名作为盐值没有问题。
更安全的存储密码的方法是为每个记录使用不同的盐值。
如果您查看 asp.net 会员资格提供商的 aspnet_Membership 表，您会发现他们将密码、密码盐和用户名字段存储在几乎相同的记录中。因此，从这个角度来看，仅使用用户名作为盐值没有安全差异。
请注意，某些系统对所有密码使用单个盐值，并将其存储在配置文件中。这里安全性的唯一区别是，如果他们能够访问单个盐值，那么他们可以更轻松地构建彩虹表来一次破解所有密码......
但话又说回来，如果他们有权访问加密形式的密码，那么他们可能就可以访问存储在用户表中的盐值...这可能意味着他们在计算密码值时会遇到一些困难。
然而，归根结底，我相信几乎所有应用程序都在加密方面失败，因为它们只加密表面上最不重要的数据之一：密码。真正应该加密的几乎是其他一切。
毕竟，如果我可以访问您的数据库，为什么我会关心密码是否加密呢？我已经可以访问重要的事情了……
显然还有其他考虑因素在起作用，但归根结底，我不会在这个问题上太担心，因为与其他问题相比，这只是一个小问题。
I don't see a problem with utilizing the username as the salt value.
A more secure way of storing passwords involves using a different salt value for each record anyway.
If you look at the aspnet_Membership table of the asp.net membership provider you'll see that they have stored the password, passwordsalt, and username fields in pretty much the same record. So, from that perspective, there's no security difference in just using the username for the salt value.
Note that some systems use a single salt value for all of the passwords, and store that in a config file. The only difference in security here is that if they gained access to a single salt value, then they can more easily build a rainbow table to crack all of the passwords at once...
But then again, if they have access to the encrypted form of the passwords, then they probably would have access to the salt value stored in the user table right along with it... Which might mean that they would have a slightly harder time of figuring out the password values.
However, at the end of the day I believe nearly all applications fail on the encryption front because they only encrypt what is ostensibly one of the least important pieces of data: the password. What should really be encrypted is nearly everything else.
After all, if I have access to your database, why would I care if the password is encrypted? I already have access to the important things...
There are obviously other considerations at play, but at the end of the day I wouldn't sweat this one too much as it's a minor issue compared others.
如果您使用用户名作为密码，并且您的应用程序有很多实例，人们可能会为特定用户（例如“admin”或“system”）创建彩虹表，就像 Oracle 数据库的情况一样，或者使用整个通用名称列表（例如它们）为WPA（CowPatty）做的
你最好采取真正随机的盐，这并不困难，而且它不会回来困扰你。
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 摘要身份验证的工作组来说，该方法被认为足够安全，该身份验证使用字符串“用户名：领域：密码”的哈希进行操作。
我想你会很高兴看到这个决定是秘密的。如果有人窃取您的数据库和源代码来查看您实际上是如何实现散列的，那么他们当时登录以访问什么？显示他们已经窃取的数据库中的数据的网站？
在这种情况下，盐可以为您的用户带来一些安全优势。首先，如果窃贼有预先计算的值（彩虹表），他们就必须为每个用户重新计算这些值才能进行攻击；如果小偷想要的是单个用户的密码，那么这并不是一个大胜利。
其次，即使所有用户共享相同的密码，他们的哈希值也总是不同的，因此窃贼不会免费获得任何哈希冲突（破解一个用户获得 300 个密码）。
这两个好处有助于保护可能在多个站点使用相同密码的用户，即使窃贼碰巧获取了其他站点的数据库。
因此，虽然用于密码散列的盐最好保密（在您的情况下，用于盐的确切数据就是），但即使它受到损害，它仍然可以提供好处。
This method was deemed secure enough for the working group that created HTTP digest authentication which operates with a hash of the string "username:realm:password".
I think you would be fine seeing as this decision is secret. If someone steals your database and source code to see how you actually implemented your hashing, well what are they logging in to access at that point? The website that displays the data in the database that they've already stolen?
In this case a salt buys your user a couple of security benefits. First, if the thief has precomputed values (rainbow tables) they would have to recompute them for every single user in order to do their attack; if the thief is after a single user's password this isn't a big win.
Second, the hashes for all users will always be different even if they share the same password, so the thief wouldn't get any hash collisions for free (crack one user get 300 passwords).
These two benefits help protect your users that may use the same password at multiple sites even if the thief happens to acquire the databases of other sites.
So while a salt for password hashing is best kept secret (which in your case the exact data used for the salt would be) it does still provide benefits even if it is compromised.
随机加盐可防止比较同一用户名的两个独立计算的密码哈希值。如果没有它，就可以测试一个人在一台机器上的密码是否与另一台机器上的密码匹配，或者密码是否与过去使用的密码匹配等等，而无需拥有实际的密码。即使密码可用，它也将极大地方便搜索上述标准（因为可以搜索计算出的哈希值，而不是为每个旧密码哈希值单独计算哈希值）。
至于这种预防是好事还是坏事，谁知道呢。
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.
我知道这是一个老问题，但对于任何基于这个问题寻找解决方案的人来说。
如果您使用派生盐（而不是随机盐），则应使用 PBKDF2 等密钥派生函数来增强盐源。
因此，如果您的用户名是“theunhandledexception”，则将其通过 PBKDF2 进行 x 次迭代，以生成 32 位（或您需要的任何长度的盐）值。
使 x 伪随机（而不是像 1,000 这样的偶数）并将静态站点特定的 salt 传递给 PBKDF2，这样您的用户名 salt 就不可能与任何其他站点的用户名 salt 相匹配。
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.