使用随机盐改进密码散列
我正在创建一个网站，并尝试决定如何加密用户密码以将其存储在 SQL 数据库中。
我意识到使用简单的 md5（密码）是非常不安全的。我正在考虑使用 sha512(password.salt)，并且我一直在研究生成有用盐的最佳方法。 我读过很多文章，指出盐应该尽可能随机，以向散列添加熵，这看起来是个好主意。但是：
- 您需要将随机盐与散列一起存储
- ，因为攻击者以某种方式访问了您的散列密码（并试图将散列反转为纯文本），这意味着他可能转储了您的数据库，然后访问了您的随机盐也是
数据库中哈希旁边看起来奇怪的值是盐，这不是很明显吗？如果攻击者可以访问盐和哈希值，那么如何更安全？
有人在该领域有专业知识吗？谢谢！
I'm starting a website and I'm trying to decide how to encrypt user passwords to store them in a SQL database.
I realize that using a simple md5(password) is very unsecured. I'm considering using a sha512(password.salt), and I have been researching the best way to generate a useful salt.
I read numerous articles stating that a salt should be as random as possible to add entropy to the hash and it looks like a great idea. But:
- you need to store the random salt along with your hash
- given that an attacker somehow got access to your hashed passwords (and is trying to reverse the hash to plain text), it means he probably dumped your database, then got access to your random salts also
Isn't it obvious that the weird looking value next to the hash in the database is a salt? If the attacker can access the salt along with the hash value, how is that more secure?
Anyone has any expertise in that area? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
攻击者“被允许”知道salt - 您的安全性设计必须确保即使知道salt，它仍然是安全的。
盐有什么作用？
盐有助于使用预先计算的“彩虹表”来防御暴力攻击。
对于攻击者来说，盐使得暴力破解的成本更高（在时间/内存方面）。
计算这样一张表的成本很高，并且通常仅在可用于多个攻击/密码时才进行。
如果您对所有密码使用相同的盐，攻击者可以预先计算这样的表，然后将您的密码暴力破解为明文...
只要您为每个要存储散列的密码生成一个新的（最佳加密强度）随机盐，就没有问题。
如果您想进一步增强安全性
您可以多次计算哈希值（哈希哈希值等） - 这不会花费您太多费用，但它会使暴力攻击/计算“彩虹表”更加昂贵......请不要发明自己- 有经过验证的标准方法可以做到这一点，例如参见 http://en.wikipedia.org/wiki/PBKDF2和 http://www.itnewb.com/tutorial/使用 RSA-PBKDF2 标准加密密码与 PHP-for-Storage
注意：
现在使用这样的机制强制，因为“CPU 时间”（可用于彩虹表/暴力破解等攻击）变得越来越广泛（例如，亚马逊的云服务跻身最快的 50 名）世界各地的超级计算机，任何人都可以以相对较小的金额使用）！
An attacker is "allowed" to know the salt - your security must be designed in a way that even with the knowledge of the salt it is still secure.
What does the salt do ?
Salt aids in defending against brute-force attacks using pre-computed "rainbow-tables".
Salt makes brute-force much more expensive (in time/memory terms) for the attacker.
Calculating such a table is expensive and usually only done when it can be used for more than one attack/password.
IF you use the same salt for all password an attacker could pre-compute such a table and then brute-force your passwords into cleartext...
As long as you generate a new (best cryptogrpahically strong) random salt for every password you want to store the hash of there is no problem.
IF you want to strengthen the security further
You could calculate the hash several times over (hash the hash etc.) - this doesn't cost you much but it makes a brute-force attack / calculating "rainbow-tables" even more expensive... please don't invent yourself - there are proven standard methods to do so, see for example http://en.wikipedia.org/wiki/PBKDF2 and http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard
NOTE:
Using such a mechanism is these days mandatrory since "CPU time" (usable for attacks like rainbow tables/brute force etc.) is getting more and more widely available (see for example the fact that Amazon's Cloud service is among the top 50 of fastest supercomuters worldwide and can be used by anyone for a comparatively small amount)!
目的是击败“彩虹表”：
http://en.wikipedia.org/wiki /Rainbow_table
在“防御彩虹表”部分中了解为什么足够长的盐会击败任何彩虹表。
它曾经更安全，因为它迫使攻击者尝试一种当时成本非常高的暴力方法，而不是立即查看预先计算的彩虹表。如果你有 64 位 salt，攻击者需要有 2^64 个预先计算的彩虹表，而不是一个……换句话说：它使彩虹表变得毫无用处。
但请注意，现代 GPU 每秒可以破解数十亿个密码，这使得攻击者存储巨大的彩虹表几乎毫无意义（不是存储数十亿个哈希值，而是只需在几秒钟内计算它们）。
现在你想使用 PBKDF2 或 scrypt 之类的东西来存储你的“密码”。
The whole point of salting is to defeat "rainbow tables":
http://en.wikipedia.org/wiki/Rainbow_table
See why a sufficiently long salt defeats any rainbow table under the section "Defense against rainbow tables".
It used to be more secure because it forced the attacker to try a, back then, very costly brute-force approach instead of an instant looked in precomputed rainbow tables. If you had a 64 bit salt, the attacker needed to have 2^64 precomputed rainbow tables instead of one... In other words: it made rainbow tables useless.
Note however that modern GPUs can crack billions of passwords per second making it mostly pointless for an attacker to store huge rainbow tables (instead of storing billions of hashes, simply compute them in a few seconds).
Nowadays you want to store your "passwords" using something like PBKDF2 or scrypt.
散列加盐密码的强度取决于以下所有因素：
您的系统的强度与上述中最弱的一个一样强。
The strength of your hashed, salted passwords rely on all of the following factors:
Your system is as strong as the weakest of the above.
以下问题来自姊妹网站 Security StackExchange。他们讨论了哈希、盐、PBKDF2、bcrypt、scrypt 和其他一些东西。
StackOverflow 上也有一些之前的讨论：
BCrypt 好吗C# 中使用的哈希算法？我在哪里可以找到它？
简而言之，盐是一种保护措施，它使得在发生泄露时需要很长时间才能恢复密码，就像哈希一样。如果攻击一个密码，盐不会产生任何影响。如果尝试使用预先计算的字典或同时测试多个密码，则每个条目使用不同的盐将大大增加所需的工作量，并且通常会使生成合适的彩虹表变得不可行。
The questions below are from the sister site Security StackExchange. They discuss hashing, salts, PBKDF2, bcrypt, scrypt, and a few other things.
There's also some previous discussion from here on StackOverflow as well:
Is BCrypt a good hashing algorithm to use in C#? Where can I find it?
In short answer to you question, a salt is a safeguard that makes it take a long time to recover a password in the event of compromise just as a hash is. If attacking one password, the salt won't make a difference. If trying to use a pre-computed dictionary or test many passwords at the same time, having a different salt for each entry will greatly increase the amount of work needed and generally make generating a suitable rainbow table infeasible.
这是一篇关于密码学的好文章：http://www. javacodegeeks.com/2012/02/introduction-to-strong-cryptography-p1.html
请参阅哈希算法的实际使用、场景部分1 对于盐的讨论。
我强烈建议使用 http://docs.oracle.com /javase/6/docs/api/java/security/SecureRandom.html 生成盐
Here's a good article on cryptography: http://www.javacodegeeks.com/2012/02/introduction-to-strong-cryptography-p1.html
See the section Real World Usage of Hash Algorithms, Scenario 1 for discussion of the salt.
I highly recommend using http://docs.oracle.com/javase/6/docs/api/java/security/SecureRandom.html to generate your salt