PHP 和 MySQL Salt 安全问题
如果我的服务器遭到黑客攻击，并且黑客查看了我的哈希密码并可以看到我使用的盐，该怎么办？
有什么值得担心的吗？
What if my server gets hacked and the hacker views my hashed passwords and can see what salt I was using.
Is it something to worry about?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
这不应该是一个问题。盐值的想法是它可以防止彩虹攻击（使用预先计算的值）。所以知道盐值并不会暴露出问题。
It is not supposed to be a problem. The idea with salt values is that it prevents a rainbow attack (using precomputed values). So knowing the salt value does not expose a problem.
是的。现在黑客可以暴力破解它们（如果他知道你实际上是如何对密码加盐的）。
无需担心 - 由于您使用的是加盐密码，因此无法应用更智能的攻击（暴力破解除外）。
Yes it is. Now hacker can bruteforce them (if he knows how actually you salted the passwords).
Nothing more to worry - since you're using the salted passwords more intelligent attacks (other than bruteforce) cannot be applied.
如果黑客已经进入您的系统并访问了数据库，那么就您的用户隐私而言，“游戏结束”了！黑客拥有他想要的一切，除了用户密码，除了欺骗用户访问的机会外，他没有提供任何他还没有得到的东西——>他可以非常简单地通过将自己的哈希值和盐放入数据库来完成此操作！
所以，在这种情况下，MD5 加盐是“足够好的”安全性。
If the hacker has gotten into your system and has access to the database then its "game over" as far as your users privicy is concerned! The hacker has everything he wants except the users passwords which dont give anything he hasnt got already apart from the opperunity to spoof a user access --> which he can do very simply by putting his own hash and salt in the database!
So yes MD5 plus salt is "good enough" security in this case.
要查看 salt，他必须拥有源代码，当他拥有源代码时，至少有一些事情需要担心 - 他将看到负责创建密码的机制以及为密码加盐的方法。
To see the salt he must have the source code, and when he has it, there are at least some things to worry about - he will see the mechanism responsible of creating password and a way of salting them.
是的。他仍然需要反转哈希值，这无论如何都不容易，但现在他知道明文的关键部分。盐加字典攻击比通过网络窥探（不知道盐）更有可能成功。
Yes. He'd still need to reverse the hash, which isn't easy by any means, but now he knows a key part of the plaintext. The salt plus a dictionary attack is much more likely to succeed than snooping over the wire (with no knowledge of the salt) would be
本质上，盐只是让密码变得更强。如果他拥有存储您的密码的任何内容并且可以进行暴力攻击，那么当他最终解密的任何密码都相同时，他就可以找出盐，这对解密个人密码没有帮助。
http://pbeblog.wordpress.com/ 2008/02/12/secure-hashes-in-php-using-salt/
这篇文章有一个很好的解释......所以是的，如果黑客可以看到你的源代码，你应该担心，但仅盐没什么大不了的。
Essentially the salt just makes the password stronger. It won't aid in the decryption of individual passwords if he has whatever your passwords are stored in and can run brute force attacks he can just figure out the salt when it ends up being the same in whatever passwords he decodes.
http://pbeblog.wordpress.com/2008/02/12/secure-hashes-in-php-using-salt/
This article has a pretty good explanation... so yes if the hacker can see your source code you should be worried but the salt alone isn't a big deal.
我不是这个主题的专家，但这是我的理解：
给定一个盐，攻击者可以构建所谓的“彩虹表”，这基本上是哈希函数的逆过程。通过此表，他们可以在表中查找加密值并取回输入密码，这样
hash(password + salt) = 加密值。然而，虽然查找速度很快，但构建彩虹表非常耗时。您可以做的一个简单的事情是为每个帐户随机生成一个盐值并将其与加密密码一起存储。这样，如果攻击者想要获取密码，他们就必须为每个用户构建一个彩虹表，而不是在整个站点范围内构建一个。
（有盐仍然比没有好得多，因为这样攻击者至少必须生成自己的彩虹表，而不是仅仅下载库存的）。
更多信息，可能是更好的答案
I am not an expert in this subject, but this is my understanding:
Given a salt, an attacker can build what's known as a "rainbow table", that's basically a reverse of the hash function. With this table, they can lookup an encrypted value in the table and get back an input password such that
hash(password + salt) = encrypted value.However, while lookups are quick, rainbow tables are very time consuming to build. A simple thing you can do is to generate a salt value randomly on a per-account basis and store it alongside the encrypted password. That way, if an attacker wanted to get passwords out, they would have to build a rainbow table for each user as opposed to building one site-wide.
(Having a salt is still much better than nothing because that way an attacker has to at least generate his own rainbow table as opposed to just downloading a stock one).
More information, and probably a better answer
如果您对所有密码仅使用一个盐，则黑客可以预先计算盐渍彩虹表，这将使他能够相当快速地访问所有密码。
您可以为每个单独的密码使用随机盐，这意味着黑客必须为每个盐计算这样的彩虹表，实际上是暴力破解每个密码，这会显着减慢他的速度。
您可以通过使用故意减慢的哈希来进一步减慢他的速度，这会将暴力破解减慢到可能变得不可行的程度。 MD5 是最糟糕的选择，因为它真的很快（并且启动时很困难）。 SHA 系列的设计速度也很快，但却是更好的选择。 Bcrypt 或一般的 *fish 系列都不错，但系统和语言之间的支持各不相同。请小心使用 *fish 的哈希变体，因为它们也用于加密（可以逆转）。
请参阅
If you're using only one salt for all passwords, a hacker can pre-compute a salted rainbow table, which will give him access to all passwords rather quickly.
You can use a random salt for each individual password, which means a hacker would have to compute such a rainbow table for every salt, in effect brute-forcing every single password, which would slow him down quite significantly.
You can further slow him down by using a deliberately slow hash that will slow down brute-forcing to a point where it may become infeasible. MD5 is the worst choice because it's really fast (and broken to boot). The SHA family was also designed to be fast, but is a better choice. Bcrypt or generally the *fish family is decent, but support among systems and languages varies. Be careful to use a hash variant of *fish, since they are also used for encryption (can be reversed).
See http://blog.phusion.nl/2009/08/13/securely-store-passwords-with-bcrypt-ruby-now-compatible-with-jruby-and-ruby-1-9/.