我正在做一些研究或搜索处理密码散列和加盐的不同方法，并遇到了这个有趣的链接：
现在，基本上这个提议是创建两个用户函数，一个用于散列，一个用于检查散列。
盐是伪随机的，但实际上是基于密码的（让我觉得很糟糕？）。
散列函数还伪随机地在散列字符串中“撒”盐。
哈希检查功能反转撒盐，然后进行实际的哈希检查。
现在，我知道每个密码散列的唯一盐 = 好，但也有逻辑散列密码并创建存储在 db 函数中的盐可能 = 坏。
我喜欢盐不明显的想法，它也不需要基于一些希望一致的值，例如用户名、用户 ID、出生日期等，但正如我所说，我确实对实施表示怀疑。
那么，人们对“最佳方法解决方案”的看法和想法是什么？
盐不需要保密。对于给定的密码，它确实需要是不可预测的。
从密码中提取盐完全没有抓住重点。
盐的目的是使彩虹表的使用变得异常昂贵，因此尝试 1 几乎正确地解决了这个问题。基于密码的盐消除了破坏彩虹表的可变性，并且试图将其隐藏在散列密码字段中是毫无意义的。
我之前问过一个类似的问题。共识是这样的：
你如何加盐并不重要，只要你：
您甚至可以将您的盐存储在您的散列密码旁边，并感到非常自信。
就我个人而言，我发现 GUID（字符串格式）非常适合 Salts。它们需要一行代码来生成，并且字符串格式的大小足以让彩虹表花费数千年的时间来计算。
（编辑答案，因为我最初误读了这篇文章，并认为他只是将盐与未加盐的哈希混合在一起）
他的技术看起来确实不错，它们会起作用，但它们并不比普通的腌制方法“更好”。这只是通过默默无闻来做安全的尝试，它并不比自己制作随机的“哈希加扰”方法并希望攻击者没有弄清楚更好。
事实上，在许多情况下，攻击者实际上很容易找出这些功能。如果该站点是公开注册的站点，则攻击者可以重复注册具有已知密码的帐户，然后使用这些密码的已知 md5 散列来对密码加扰算法进行逆向工程。即使看看他的“尝试4”的结果，我也可以很容易地做到这一点。
如果您想真正安全地存储您的密码，请远离 MD5 甚至 SHA1，转而使用加盐的、较慢的散列函数。这是一篇关于该主题的精彩文章：彩虹表足够了：您需要了解的有关安全密码方案的知识
对我来说，这似乎只是为（正如 Chad Birch 指出的被误解的）加盐哈希方法添加了混淆，而不是更多的安全性。
有趣的是，这不仅仅是混淆，不是更多的安全性，而是实际上的混淆，更少的安全性，因为“尝试 4”仅与它使用的 CRC32 函数一样好（CRC32 仅传递密码，而不是密码+盐） - 这是倒台。
根据 Chad 的帖子，要破解“尝试 4”，只需 CRC32 加载密码，然后反转他编写的函数，留下一个加盐的 md5 哈希和盐（然后您将测试其有效性） . 只需通过计算 md5(password+salt) （其中密码是您正在尝试的密码）来测试这对，盐是您通过反转算法计算的盐。如果 md5 等于散列的前 32 个字符，则您已经破解了密码。
在某些方面，“尝试 4”比“尝试 1”更糟糕，因为它仅与整个例程中调用的最差函数一样好，在本例中为 CRC32（密码）。
我无法查看原始问题中的链接（该网站仅返回 404 not found 错误），但问题中描述的方法并没有真正使用加盐哈希。
本质上，这种方法只是使用非标准哈希：给定一个特定的密码，数据库中将存储一个唯一值。这就是使彩虹表攻击起作用所需的全部内容：我可以为可能的密码字典预先计算哈希值并查找任何匹配项。现在，我将不得不专门为这个非标准哈希函数预先计算彩虹表。
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.