如果我为每个用户设置随机 SALT，我该如何验证他们的身份？
我一直在研究加盐和散列密码的好处，但有一件事仍然让我困惑......
当我为每个用户提供随机盐时，当我尝试对他们进行身份验证时，我如何知道盐是什么登录？
所以如果我这样做..
HASHPW = PW.RANDOMNUMBER
我可以将随机数存储在数据库中，但这似乎消除了添加盐的全部意义..不是吗？我也可以为每个盐使用一个非随机数，但这也会消除盐的意义，因为如果他们发现他们拥有我所有的用户密码......
我刚刚开始学习 PHP 和 MySQL 以及像这样的抽象事物一直让我困惑
谢谢！
I've been reading up on the benefits of salting and hashing passwords, but one thing still eludes me...
When I provide a random salt for each user, how do I then know what the salt was when I try to authenticate them to login?
so if I do..
HASHPW = PW.RANDOMNUMBER
I could store the random number in the database, but that seems to kill the entire point of adding the salt.. doesn't it? I could also use a non random number for each salt, but then that also kills the point of the salt because if they figure it out they have all my users passwords...
I just started learning PHP and MySQL and abstract things like this have been confusing me
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
它并没有违背独特的盐来储存它的目的。独特盐的目的是保护您的整个用户存储库免受攻击，而不是保护给定的单个用户。如果攻击者破坏了您的数据库并且有足够的决心破解特定用户的帐户，他们就会这么做。我们对此无能为力。但他们必须花费大量的计算机时间来这样做 - 足够多的时间在每个用户上花费那么多时间是不可行的 - 从而保护所有用户。与此相比，对所有用户使用相同的盐 - 一旦攻击者拥有盐，就可以在相对较短的时间内针对每个用户重新运行相同的表/进程。
It doesn't defeat the purpose of the unique salt to store it. The point of a unique salt is to protect your entire users repository from attack, not a given individual user. If an attacker compromises your database and is determined enough to crack a particular user's account, they will. There's nothing we can do about this. But they would have to spend an inordinate amount of computer time doing so - enough that it would not be feasible to spend that much time on each user - thus protecting all your users. Contrast this with using the same salt for all users - once the attacker has the salt, the same tables/processes can be re-run against every user in a relatively short time.
Salt 是为每个用户随机生成的，但它保存在数据库中的某个位置。您查找特定用户的盐并使用它来验证该用户。
关键是，由于每个用户的盐是不同的，因此您不能使用预先构建的哈希字典将哈希密码映射到明文（彩虹攻击）。
Salt is randomly generated for each user but it's saved somewhere in the database. You look up the salt for the particular user and use it to authenticate the user.
The point is, since salt is different for each user, you cannot use a prebuilt dictionary of hashes to map the hashed passwords to clear text (rainbow attack).
盐可以防止某人获取您的加密密码数据库的副本并同时对所有密码发起离线攻击。它不能防止针对单个密码的攻击。
您可能会喜欢阅读原始的 Unix 密码安全文章。它很好地解释了盐是什么以及为什么我们有它们：http: //portal.acm.org/itation.cfm?id=359172
The salt prevents someone from getting a copy of your encrypted password database and mounting an offline attack against all of the passwords at the same time. It doesn't prevent attacks against a single password.
You might enjoy reading the original Unix password security article. It does a very good job explaining what a salt is, and why we have them: http://portal.acm.org/citation.cfm?id=359172
创建哈希密码时，您应该使用“双”盐
创建盐（随机 md5 或 sha1），然后使用类似 sha1("--$password--$salt--") 的格式，然后将哈希密码和盐存储在数据库中。
然后，在进行身份验证时，您可以从 --$pass--$salt-- string 重新创建哈希，并将其与存储在 db 中的 pass 进行比较。
when creating the hashed password you should use "double" salt
Create a salt (random md5 or sha1) then use format something like sha1("--$password--$salt--") and then store hashed password and salt in database.
Then, when authenticating you recreate the hash from --$pass--$salt-- string and compare it to the pass stored in db.
您不需要为每个密码使用单独的盐。
加盐的目的是抵抗彩虹表——将候选密码转换为包含盐的新字符串；由于盐是只有您拥有的私有字符串，因此知道加盐密码的哈希值对拥有普通彩虹表的攻击者没有帮助。
聪明的攻击者可以尝试通过创建帐户并更改密码来观察生成的哈希值，从而专门为您的服务构建自定义彩虹表。如果每个用户的盐都是相同的，那么当他看到哈希“xyz123”对应于“apple”，并注意到另一个用户的哈希也是“xyz123”时，他可以断定该用户的密码是“apple”。此时，大多数人决定为每个用户存储独特的盐。
然而，这是不必要的。您已经为每个用户拥有了一个唯一的字符串——用户名。不是秘密，所以不是好盐；然而，用户名和全局秘密盐的串联既是秘密的又是唯一的。如果您存储（用户名+盐+密码）的哈希值，则只需在查找时知道单个全局盐值。
（确实，如果有人泄漏单一全局盐，这会带来更大的风险。但这是一项值得考虑的技术）。
You do not need a separate salt for every password.
The purpose of salting is to resist rainbow tables -- you convert a candidate password into a new string that has your salt in it; since the salt is some private string only you possess, knowing the hash of a salted password will not help an attacker who has a run of the mill rainbow table.
A clever attacker can try to build a custom rainbow table just for your service by creating an account, and changing his password to observe what the resulting hash is. If the salt is the same for every user, then when he sees that the hash "xyz123" corresponds to "apple", and notices that another user's hash is also "xyz123", he can conclude that that user's password is "apple". This is the point where most people decide to store a unique salt for each user.
However, this is unnecessary. You already have a unique string for each user -- the username. It's not secret, so it is not a good salt; however the concatenation of the username and a global secret salt is both secret and unique. If you store the hash of (username+salt+password), you only need to know the single global salt value at lookup time.
(it's true that this poses a greater risk if someone leaks the single global salt. But it's a technique worth considering).