对密码哈希加盐有什么好处？
我刚刚读过很多很多关于用盐哈希密码的文章，但我只是找不到我所遇到的特定查询/困惑的答案。
假设我刚刚完成了向数据库添加密码和盐的方法：
- 创建一个随机盐
- 将用户密码+盐散列在一起
- 将散列输出存储为“密码”列中的密码
- 将随机盐存储在“盐”列中
如果这是正确的，当攻击者访问我的数据库时会发生什么？当然，如果他们可以读取该哈希密码的盐值，他们就可以计算出没有盐的哈希密码是什么，然后使用彩虹表？或者用可逆的东西来加密盐值是个好主意吗？
如果盐值以纯文本形式存储，我就看不到它的意义。请赐教？
I have just read many, many articles on SO about hashing passwords with salt but I just cannot find an answer to the particular query/confusion I have.
Let's say I have just done this method for adding a password and salt to the DB:
- Create a random salt
- Hash the users password + salt together
- Store the hash output as the password in column 'password'
- Store the random salt in column 'salt'
If this is correct, what happens when an attacker gets access to my DB? Surely if they can read what the salt value is for that hashed password, they can work out what the hashed password is without the salt and then use a rainbow table? Or is it a good idea to encrypt the salt value too with something that is reversible?
If the salt value is stored in plain-text, I just cannot see the point of it. Please enlighten me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果攻击者到达数据库，那么所有的赌注都会被取消，但就盐而言......
盐的目的不是保密，而是阻止彩虹攻击——彩虹攻击是通过彩虹表完成的攻击。彩虹表只是预先生成数以百万计的密码的哈希值（这是一种时空权衡）。盐的引入会使这些预先计算的哈希值无效：必须为每个唯一的盐创建一个彩虹表。
所以...
现在，如果假设攻击者拥有数据库，那么还有另一个问题：攻击速度不受限制，这就是密码散列方案的原因像 bcrypt 或多轮是有价值的。它可以将攻击速度从每秒数亿哈希（MD/SHA 和朋友设计得很快）降低到每秒几百次。第二（在相同的硬件上）...还要考虑 HMAC 方法，该方法还包含服务器秘密（使其有效地密码+盐+秘密）。
（我只会使用已经解决所有这些问题以及更多问题的现有系统:-)
快乐编码。
If the attacker gets to the database then all bets are off, but as far as salt ...
The point of a salt is not to be secret but rather to thwart rainbow attacks -- a rainbow attack is one which is done through a rainbow table. And a rainbow table is just pre-generated hashes of millions and millions of passwords (it's a space-time tradeoff). The introduction of a salt invalidates these precomputed hashes: a rainbow table must be made for each unique salt.
So...
Now, if the attacker is assumed to have the database then there is another problem: the attack speed is not limited, and this is why a password hashing scheme like bcrypt or multiple-rounds is valuable. It can slow down the attack-speed from hundreds of millions of hashes per second (MD/SHA and friends were made to be fast) to, say, a few hundred per second (on the same hardware)... Also consider an HMAC approach, which also incorporates a server-secret (making it effectively password+salt+secret).
(I would just use an existing system that already addresses all these issues, and more :-)
Happy coding.
您概述的步骤是正确的。
如果攻击者访问您的数据库，他必须对可能的密码和随机盐进行强力搜索。如果您使用 64 位相当随机的盐，则不会有两个条目使用相同的盐，因此任何彩虹表攻击一次仅适用于（最多）一个盐值，这使得彩虹表攻击也昂贵才值得。 （当您为用户建立盐时，您甚至可以检查以确保没有其他密码使用给定的盐。）
加盐哈希密码过程的要点是使预先计算可能的密码哈希在计算上不可行，因为随机salt 搞乱了预计算过程。
这也意味着，如果在不同站点使用相同的密码，仅通过查看（加盐哈希）密码值就不会很明显 - 因为不同站点的盐会不同，因此生成的哈希值将是不同的。 （当然，如果在一个站点发现了密码，那么攻击者将首先在下一个站点尝试该密码；最好不要在多个位置使用相同的密码。但事实上，相同的密码正在使用被隐藏。）
The steps you outline are correct.
If the attacker accesses your database, he has to do a brute force search of the possible passwords plus the random salt. If you use a 64-bit reasonably random salt, then there won't be two entries using the same salt, so any rainbow table attack only works for (at most) one salt value at a time, which makes the rainbow table attack too expensive to be worthwhile. (You can even check to ensure that there is no other password using a given salt when you establish the salt for a user.)
The point of the salted hashed password process is to make it computationally infeasible to precompute possible password hashes, because the random salt screws up the precomputation process.
It also means that if the same password is used at different sites, it won't be obvious by simply looking at the (salted hashed) password values - because the salts will be different at the different sites, so the resulting hash value will be different. (Of course, if the password is discovered for one site, then the attacker will try that password first at the next site; it is still best not to use the same password in multiple locations. But the fact that the same password is in use is hidden.)
假设您没有使用盐，并且攻击者获得了您的哈希值。她所需要做的就是将哈希值与查找表进行比较，看看是否有任何哈希值是已知密码的。假设该表中有一百万个密码。她可以非常有效地对照一百万个可能的密码检查您的所有哈希值。
现在假设同一个攻击者获得了您的哈希值，但它们是加盐的。对于她想要检查的每个哈希值，她需要获取候选密码，应用盐，计算新的哈希值，并将其与您存储的哈希值进行比较。现在她必须做大量的计算，而且效率不高。 （或者，她可以有一个包含所有可能的盐的查找表，但是好吧，那么她需要有一个比没有盐的查找表大几个数量级的查找表。）
这一切都是为了制作所需的资源量破解哈希值超出了攻击者的价值。
Let's say you didn't use a salt and an attacker got your hashes. All she'd need to do to is compare the hashes to a lookup table and see if any of the hashes are for known passwords. Let's say the table has a million passwords in it. She can very efficiently check all your hashes against a million possible passwords.
Now let's say the same attacker got your hashes, but they are salted. For each hash she wants to examine, she'll need to take the candidate password, apply the salt, compute a new hash, and compare it to the hash you have stored. Now she has to do a ton of calculations and it's not as efficient. (Alternatively, she could have a lookup table with every possible salt in it, but OK, then she needs to have a lookup table that is orders of magnitude larger than the one without salts.)
It's all about making the amount of resources required to crack the hashes more than it's worth to the attacker.