密码哈希和加盐 - 这是一个好方法吗？
我正在做一些研究或谷歌搜索处理密码散列和加盐的不同方法，并发现了这个有趣的链接：
现在，本质上它建议的是创建两个用户函数，一个用于散列，一个用于检查散列。
盐是伪随机的，但实际上是基于密码的（让我觉得很糟糕？）。
散列函数还伪随机地将盐“撒”在散列字符串中。
哈希检查功能反转撒盐，然后进行实际的哈希检查。
现在，我知道每个密码散列的唯一盐 = 好，但拥有散列密码并创建存储在数据库函数中的盐的逻辑可能 = 坏。
我喜欢这样的想法，即盐不明显，也不需要基于一些希望一致的值，例如用户名、用户 ID、出生日期等，但正如我所说，我确实对实现存在疑问。
那么，人们对“最佳方法解决方案”的看法和想法是什么？
I was doing a little research or googling for different methods of handling password hashing and salting and came across this interesting link:
Now, essentially what this proposes is the creation of two user functions, one for hashing and one for checking the hash.
The salt is pseudo random but is in actual fact based upon the password (strikes me as bad?).
The hashing function also pseudo randomly "sprinkles" the salt amongst the hash string.
The hash checking function reverses the salt sprinkling and then the actual hash check takes place.
Now, I'm aware that unique salts for each password hash = good, but also that having the logic to hash the passwords and create the salt stored in a db function might = bad.
I like the idea that the salt isn't obvious and that it also needn't be based on some hopefully consistent value such as username, userid, date of birth etc, but as I said I do have my doubts as to the implementation.
So, what are people's opinions and ideas of "best approach solutions"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
盐的目的是使 rainbow table 的使用变得过于昂贵，因此尝试 1几乎正确地解决了问题。 基于密码的盐消除了击败彩虹表的可变性，并且尝试将其隐藏在散列密码字段中是毫无意义的。
The purpose of a salt is to make the use of a rainbow table prohibitively expensive, so Attempt 1 pretty much solves the problem correctly. Basing the salt on the password eliminates the variability that defeats rainbow tables, and trying to hide it in the hashed password field is just pointless.
我之前问过一个类似问题。 共识是：
如何加盐并不重要，只要您：
您甚至可以将盐存储在哈希密码旁边，并感到非常自信。
就我个人而言，我发现 GUID（字符串格式）非常适合 Salts。 它们需要一行代码来生成，并且以字符串格式存储，其大小足以使彩虹表需要数千年的时间来计算。
I asked a similar question earlier. The consensus was this:
It doesn't matter how you salt, so long as you:
You can even store your salt right next to your hashed passwords and feel pretty darn confident.
Personally, I find GUIDs (in string format) work great for Salts. They take a line of code to generate and in string format are more than large enough to make rainbow tables take millennia to compute.
之前有很多类似的问题被问过：
这应该会让您了解如何散列密码。
There have been many similar questions asked before:
That should get you an idea of how to hash passwords.
（编辑答案，因为我最初读错了这篇文章，认为他只是将盐与未加盐的哈希混合在一起）
他的技术看起来确实不错，它们会起作用，但它们并不是真正的“更好” “比普通的腌制方法。 这只是一种通过默默无闻来实现安全性的尝试，这并不比编写自己的随机“哈希加扰”方法并希望攻击者无法弄清楚更好。
事实上，在许多情况下，攻击者实际上很容易找出这些函数。 如果该网站是公开注册的，攻击者可以重复使用已知密码注册帐户，然后使用这些密码的已知 md5 哈希值来对密码加扰算法进行逆向工程。 即使查看他的“尝试 4”的结果，我也能非常轻松地做到这一点。
如果您想真正安全地存储密码，请远离 MD5 甚至 SHA1，而转向使用加盐的、速度较慢的哈希函数。 这是一篇关于该主题的精彩文章：彩虹表已经足够了：关于安全密码方案您需要了解的内容
(Edited answer because I misread the article initially and thought he was just mixing the salt together with an unsalted hash)
His techniques do seem fine, they'll work, but they're not really any "better" than normal salting methods. It's just an attempt to do security by obscurity, it's no better than making up your own random "hash scrambling" method and hoping that the attacker doesn't figure it out.
In fact, it could actually be quite easy for the attacker to figure these functions out, in many cases. If the site is one with public registration, the attacker could repeatedly register accounts with known passwords, then use the known md5 hashes for those passwords to reverse-engineer the password scrambling algorithm. I'd be able to do this very easily, even looking at the result of his "Attempt 4".
If you want to store your passwords really securely, get away from MD5 and even SHA1, and move towards a salted, slower hash function. This is a great article about the topic: Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes
对我来说，这似乎只是在加盐哈希方法中添加混淆，不再安全（正如 Chad Birch 指出的误解）。
This seems for me to just add obfuscation, not any more security, to the (as Chad Birch pointed out misunderstood) salted hash method.
有趣的是，这不仅仅是混淆，不再安全，而是实际上混淆，安全性降低，因为“尝试 4”仅与它使用的 CRC32 函数一样好（CRC32 是仅传递密码，而不是密码+盐） - 这是失败。
根据 Chad 的帖子，要破解“尝试 4”，所要做的就是 CRC32 加载密码，然后反转他编码的函数，留下加盐的 md5 哈希值和盐（然后您将测试其有效性） 。 只需通过计算 md5（密码+盐）（其中密码是您正在尝试的密码）来测试这一对，盐是您通过反转算法计算出的盐。 如果 md5 等于哈希值的前 32 个字符，则您已经破解了密码。
在某些方面，“尝试 4”比“尝试 1”更糟糕，因为它与整个例程中调用的最差函数一样好，在本例中为 CRC32（密码）。
Interestingly, this is not just obfuscation, not any more security but actually obfuscation, less security because "Attempt 4" is only as good as the CRC32 function it uses (CRC32 is passed ONLY the password, not password+salt) - this is the downfall.
As per Chad's post, to crack "Attempt 4", all one has to do is CRC32 loads of passwords and then reverse the function he's coded up, leaving you with a salted md5 hash and the salt (which you would then test for validity). Simply test this pair by calculating md5(password+salt) (where password is the password you are trying) and salt is the salt you have calculated by reversing the algorithm. If the md5 equals the first 32 characters of the hash, you've cracked the password.
"Attempt 4" is worse than "Attempt 1", in some respects, as it as only as good as the worst function called in the entire routine, in this case, CRC32(password).
我无法查看原始问题中的链接（该网站仅返回 404 未找到错误），但问题中描述的方法并未真正使用加盐哈希。
本质上，这种方法只是使用非标准哈希：给定一个特定的密码，数据库中将存储一个唯一的值。 这就是使彩虹表攻击起作用所需的全部内容：我可以预先计算可能密码字典的哈希值并查找任何匹配项。 现在，我必须专门针对这个非标准哈希函数预先计算彩虹表。
在加盐哈希的正确实现中，当创建密码时，随机盐会与密码组合并进行哈希处理。 然后使用随机盐并存储哈希值。 即使我知道密码，我也无法预测哈希值是什么，因为许多可能的盐值中的每一个都会有一个不同的哈希值。 现在，攻击者需要为每个可能的盐值预先计算彩虹表：这需要付出更大的努力。
I can't view the link in the original question (the website just returns a 404 not found error), but the method described in the question is not really using a salted hash.
In essence, this method is just using a non-standard hash: given a specific password, there is one unique value that will be stored in the database. This is all that is needed to make a rainbow tables attack work: I can precompute the hash value for a dictionary of likely passwords and look for any matches. Now, I will have to precompute rainbow tables specifically for this non-standard hash function.
In a proper implementation of salted hashes, when the passord is created, a random salt is combined with the password and hashed. Then random salt used and the hash are stored. Even if I know the password, I cannot predict what the hash will be since there will be a different hash for each of the many possible salt values. Now an attacker needs to precompute a rainbow table for each possible salt value: this takes a much larger effort.
盐不需要保密。 对于给定的密码来说，它确实需要是不可预测的。
从密码中导出盐完全没有抓住要点。
The salt doesn't need to be secret. It does need to be unpredictable for a given password.
Deriving the salt from the password completely misses the point.