有人可以解释一下盐在存储哈希密码时有何帮助吗？
我很难理解当密码或其他重要信息的数据库遭到破坏时，附加到哈希值的盐如何帮助提高安全性。
例如，如果盐是“hello”，并附加到密码“password”，则盐和密码将存储在一起，“hellopassword”并散列以生成：
94e66f94517d606d5ad6d9191b980408952f2ed2 (sha1)
然后附加盐：
hello$94e66f94517d606d5ad6d9191b980408952f2ed2
这如何更安全？攻击者知道盐，所以现在可以毫不费力地计算密码......对吧？或者我从根本上误解了什么？
I am having difficulty understanding how a salt which is appended to a hash helps improve the security when a database of passwords or other important information is compromised.
If the salt is, for example, "hello", and is appended to the password "password" then the salt and password are stored together, "hellopassword" and hashed to produce:
94e66f94517d606d5ad6d9191b980408952f2ed2 (sha1)
with the salt then appended:
hello$94e66f94517d606d5ad6d9191b980408952f2ed2
How is this more secure? The attacker knows the salt so can now compute the passwords with little extra difficulty... right? Or am I fundamentally misunderstanding something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
salt 有两种帮助：
1）当两个（或更多）人使用相同的密码时，没有 salt，您可以看到谁使用相同的密码（哈希值都是相同的）。因此从理论上讲，如果该人知道其中一个人的密码，那么他就知道每个人的密码具有相同的哈希值。这是一个次要的原因。
2）主要原因是为了防止通常称为字典攻击或彩虹攻击的攻击。在这些攻击中，有人使用预先计算的哈希值数据库作为常用密码。通常这些数据库的规模都非常大。但此时很容易根据预先计算的哈希值列表查找您拥有的哈希值（哈希密码）并查看关联的密码是什么。
通过使用盐值（通常您希望这是一个随机数），哈希值将与字典不匹配（使用所有可能的盐值预先计算所有密码的可能性会指数级增加）。因此，即使您的用户使用容易被攻击的密码，例如“密码”，它几乎可以保证是任何密码字典/彩虹表中的任何一个，通过预先设定您的随机盐值，您几乎可以保证哈希值是无用的给攻击者。同时，对于您来说，由于盐只是以明文形式存储，因此您可以轻松地将其添加到明文中，以便比较用户输入的密码。
salt helps in 2 ways:
1) When two (or more) people use the same password, without salt you can see who uses the same password (the hashes are all the same). So in theory, if that person knows one of those person's passwords he knows everyone's passwords with the same hash. This is a minor reason.
2) The main reason is to prevent attacks commonly called dictionary attacks or rainbow attacks. In these attacks someone uses a database of pre-calculated hashes for common passwords. Often times these databases are gigs in size. But it is very easy at that point to just do a lookup for the hashes you have (the hashed password) against the list of pre-calculated hashes and see what the associated password is.
By using a salt value (typically you want this to be a random number) the hash won't match the dictionary (the chance of them pre-calculating all passwords with all possible salt values is exponentially more difficult). So even if your user uses an easily attacked password, say "Password", which is pretty much guaranteed to be any in any password dictionary/rainbow table, by pre-pending your random salt value you make the hash pretty much guaranteed to be useless to the attacker. Meanwhile for you, since the salt is just stored in cleartext, it makes it very easy for you to add it to your cleartext for your comparison of the password the user entered.
盐不会附加到哈希值中，而是附加到密码上，然后进行哈希处理。这更安全，因为黑客必须知道盐和实际密码，您都应该严格保护它们。 ：D
The salt isn't appended to the hash, its appended to the password THEN hashed. This is more secure because hackers have to know the salt and the actual password, which you should both protect heavily. :D
不，不是“一点额外的困难”——而是潜在的更大的困难。
想象一下有二十亿个通用密码。对所有这些进行散列并存储结果很容易。然后，如果您有一个未加盐的密码哈希，您只需检查哪些常见密码与给定的哈希相匹配。
现在将其与加盐哈希进行比较......现在您有二十亿个通用密码，但也有数十亿个可能的盐。计算所有可能的盐/密码组合将花费非常非常长的时间 - 希望变得不可行。
此外，这意味着即使两个人拥有相同的密码，他们也很可能拥有不同的哈希值 - 因此一个用户在泄露密码时的粗心不会危及另一个人的安全。
有关详细信息，请参阅维基百科条目（如果您还没有）。
No, not with "little extra difficulty" - with potentially significantly more difficulty.
Imagine there are two billion common passwords. It's easy to hash all of those and store the results. Then if you have an unsalted password hash, you can just check which common passwords match the given hash.
Now compare that with a salted hash... now you have two billion common passwords, but also several billion possible salts. Computing all the possible salt/password combinations will take much, much longer - hopefully becoming infeasible.
Additionally, it means that even if two people have the same password, they are very likely to have different hashes - so carelessness of one user in revealing their password doesn't risk the security of the other.
See the Wikipedia entry (if you haven't already) for more on this.