使用帐户名作为盐
所以我正在为游戏制作一个网站。没有什么会流行的：P
现在我正在考虑密码安全，我将使用加盐，但是 我没有在帐户表中添加新列，而是考虑使用帐户名称作为盐，因为它无法更改，并且是“唯一的”。我的意思是 2 个用户不能拥有相同的帐户名。
但我在想如果有人的账户名为“banana”，那会有多安全。我的意思是这个词在黑客使用的这些词表中一定很流行。
假设帐户名是 Banana，密码是 hello（用 sha1 进行哈希处理），这很容易逆转，对吗？
So I'm making a website for a game. Nothing that will get popular :P
Right now I'm thinking about password security, I'm gonna use salting but
instead of adding a new column in account table I was thinking about using the account name as salt since it cant be changed, and is "unique". I mean 2 users cant have the same account name.
But I was thinking how safe it would be if lets say someone has the account name banana. I mean that word gotta be popular in these wordlist hackers use.
Lets say the account name is banana and the password is hello (hashed with sha1), that would be pretty easy to reverse am i right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
不，您应该遵循标准实践并为每个用户生成一个新的唯一盐，并将其与数据库中的其他字段一起存储，这并不难做到。
No, you should follow standard practice and generate a new unique salt per user, and just store it right along side the other fields in the database, it's not hard to do.
黑客可以在彩虹表中查找 sha 摘要，并发现它与输入“bananahello”匹配（考虑到“bananahello”已经在车辆彩虹表中）。他可以看到用户名是“banana”，因此密码是“hello”。
我会散列类似于 HTTP Digest HA1 hash: sha1(username .realm.password) 的内容。现在，为您的领域（“example.com”）定制的彩虹表很难再见。一个附带的好处是，您实际上可以在您的网站上实施摘要式身份验证，这比基本身份验证和表单要好得多。
The hacker can lookup the sha digest in the rainbow table and find that it matches the input 'bananahello' (considering that 'bananahello' is something already in the vehiculated rainbow tables). He can see that the user name is 'banana', ergo the password is 'hello'.
I would hash something similar to HTTP Digest HA1 hash: sha1(username . realm . password). Now a rainbow table customized for your realm ('example.com') is pretty hard to come bye. A side benfit is that you can actually implement Digest authentication on your site, which is sooo much better than Basic and forms.
最好不使用盐，但不如随机盐安全。
It would be preferable to not using a salt, but would not be as secure as a random salt.
至少以某种方式计算排列只有您知道的用户名以获得盐。虽然哈希值不容易逆转，但您希望保护自己免受暴力攻击。如果您使用未排列的用户名作为盐，则可以更轻松地通过字典攻击进行破解。
At least computationally permute the username somehow known only to you to get the salt. While hashes are not easy to reverse, you want to protect yourself against brute-force attacks. If you use the un-permuted username as the salt, you have made it easier to break with a dictionary attack.
没有风险。无论如何，用户名是公众所知的。而且哈希值永远不容易逆转——这就是哈希值的全部意义所在。
至于字典攻击，您可以通过密码复杂性策略来防范它。
编辑：是的，为了防止彩虹攻击，只需在盐前面加上一个较长的任意字符串即可。 SHA1("whooooohooomysiteisthebest_bananahello") 不太可能出现在彩虹表中。
There's no risk. The usernames are public knowledge anyway. And the hash is never easy to reverse - that's the whole point of hash.
As for the dictionary attack, you protect against it by having a password complexity policy.
Edit: yeah, to prevent a rainbow attack just prepend the salt with a longish arbitrary string. SHA1("whooooohooomysiteisthebest_bananahello") is not likely to be in a rainbow table.
加盐只是防止预先计算的攻击。可以有已经计算出字典盐的彩虹表，但它仍然不能阻止传统的暴力破解，这将很快遇到 Remus 的“bananahello”示例。
通过逐字使用公共用户名，您已经删除了盐的值，唯一的任务是计算该已知盐的彩虹表。所以回答你的问题，是的，你的实现很容易（但可能不会很快）逆转。
Salting just prevents pre-calculated attacks. It's possible to have rainbow tables with dictionary salts already calculated, and it still doesn't prevent traditional bruteforcing, which will stumble across Remus's example of "bananahello" example pretty quickly.
By using public usernames verbatim, you've removed the value of the salt, the only task would be to calculate a rainbow table for that known salt. So to answer your question, yes, your implementation would be easy (but maybe not quick) to reverse.