问题标签 [rainbowtable]

我在理解密码盐的用途时遇到了一些麻烦。据我了解，主要用途是阻止彩虹表攻击。然而，我见过的实现这一点的方法似乎并没有真正让问题变得更难。

我看过许多教程建议将盐用作以下内容：

原因是哈希现在不是映射到原始密码，而是密码和盐的组合。但是说$salt=fooand $password=barand $hash=3858f62230ac3c915f300c664312c63f。现在有彩虹表的人可以反转哈希并提出输入“foobar”。然后他们可以尝试所有密码组合（f、fo、foo、... oobar、obar、bar、ar、ar）。获取密码可能需要几毫秒的时间，但其他时间不多。

我见过的另一个用途是在我的 linux 系统上。在 /etc/shadow 中，散列密码实际上与salt 一起存储。例如，“foo”的盐和“bar”的密码将散列为：$1$foo$te5SBM.7C25fFDu6bIRbX1. 如果黑客能够以某种方式获得此文件，我看不出盐的用途，因为te5SBM.7C25fFDu6bIRbX已知的反向哈希包含“foo”。

感谢任何人都可以对此有所了解。

编辑：感谢您的帮助。总结一下我的理解，盐使散列密码更加复杂，从而使其不太可能存在于预先计算的彩虹表中。我之前误解的是我假设所有哈希都存在彩虹表。

假设我们有一个单词列表

我想要的是将它们生成为 MD5 哈希。（有一个 30gb 的单词表，我想把它们全部变成 MD5）我不在乎哪种语言。

这说我在单词列表中有单词“测试”所以我想要这种格式：

098f6bcd4621d373cade4e832627b4f6 = 在 MD5 中测试

re question non-random-salt-for-password-hashes Potato Head 先生指出，使用 md5 而不是 SHA-512 可以更轻松地生成彩虹表？我原以为一旦生成彩虹表，使用的算法就无关紧要了？这对您如何使用彩虹表检查已知哈希没有影响？有没有办法知道以任何方式使用了什么散列算法？

编辑更新：

我认为需要对您的密码表进行适当的哈希处理，这不是为了保护您的应用程序，而是为了保护用户将重复使用密码和 ID 的其他所有人。

好的，所以哈希的整个问题是用户输入的密码长度不能超过 15 个字符。大多数只使用 4-8 个字符，使攻击者很容易用彩虹表破解它们。

解决方案，使用用户 salt 使哈希输入更复杂，超过 50 个字符，这样他们就永远无法生成表（对于这种大小的字符串来说太大了）。另外，他们必须为每个用户创建一个新表。问题：如果他们下载数据库，他们将获得用户盐，所以如果他们足够关心，你就会回到第一方。

解决方案，使用站点“pepper”加上用户盐，那么即使他们获得了数据库，他们仍然必须知道配置文件。问题：如果他们可以进入您的数据库，他们也可能会进入您的文件系统并发现您的站点。

因此，在所有这些已知的情况下 - 让我们假设攻击者进入您的网站并获得一切，一切。那你现在怎么办？

在讨论的这一点上，大多数人的回答是“谁在乎这一点？”。但这只是一种廉价的说法，“我不知道下一步该做什么，所以它不可能那么重要”。可悲的是，我在其他任何地方都问过这个问题，这就是答案。这表明大多数程序员错过了一个非常重要的点。

让我们想象您的网站与其他 95% 的网站一样，并且用户数据——甚至是完全服务器访问权限——不值得蹲下。攻击者碰巧在追捕您的一位用户“Bob”，因为他知道“Bob”在您的网站上使用的密码与他在银行网站上使用的密码相同。他也碰巧知道鲍勃在那里有他毕生的积蓄。现在，如果攻击者可以破解我们网站的哈希值，那么剩下的就是小菜一碟了。

所以这是我的问题——如何在没有任何可追踪路径的情况下延长密码的长度？或者您如何使散列过程变得复杂以便及时复制？我想出的唯一一件事是您可以重新散列哈希数千次，并将创建最终彩虹表所需的时间增加 1,000 倍。这是因为攻击者在创建表时必须遵循相同的路径。

还有其他想法吗？

当我们说字典攻击时，我们并不是指真正的字典，对吗？我的猜测是我们的意思是黑客字典，即彩虹表，对吧？

我的意思是，我们不是在谈论有人在登录框中输入不同的密码，而是在谈论对您的数据库具有完全访问权限的人（具有散列密码，而不是普通密码），而这个人正在反转散列，对?

据我了解，生成盐的最佳做法是使用存储在源代码中的一些神秘公式（甚至是魔法常数）。

我正在做一个我们计划作为开源发布的项目，但问题是源代码带来了生成盐的秘密公式，因此能够在我们的网站上运行彩虹表攻击。

我想很多人在我之前就已经考虑过这个问题，我想知道最佳实践是什么。在我看来，如果代码是开源的，那么加盐毫无意义，因为盐很容易被逆向工程。

想法？

在过去的 2 个小时里，我一直在阅读加盐密码，以确保我理解了这个想法。我希望你们中的一些人可以就我的结论分享你们的知识。

---

如果我是攻击者，并且我获得了对用户数据库的访问权限，我可以获取表中存在的所有每个用户的盐，并使用它们来创建我的彩虹表。对于大桌子，这可能需要很长时间。如果我可以将列表缩减为感兴趣的用户（管理员、模组），我可以使用更大的字典列表来创建彩虹表，从而提高我的点击率......

如果这是真的，那么加盐似乎真的没有多大帮助。它只会稍微减慢攻击者的速度。

我知道理想情况下你会想要强制使用复杂的密码并用唯一和随机的字符串给它们加盐，但是强制使用复杂的密码会惹恼用户（我知道这让我很恼火），所以很多网站都没有这样做。似乎网站正在损害他们的用户，并且强制使用复杂的密码比一个好的加盐方法重要得多。

我想这不是一个问题，而是要求其他人了解情况。

我听说盐的唯一目的是防止彩虹表攻击，但它肯定比这更有价值吗？它不会也阻止基于字典的攻击吗？那么暴力破解呢，盐在那里有用吗？你能解释一下为什么吗？

其次，假设我有一个算法，它采用微时间、128 个字符的盐和 10 亿到 100 亿之间的随机数，并将它们散列在一起。这会提供高水平的安全性吗？因为即使攻击者知道其中一个细节，在我看来，计算其余部分在计算上仍然是不可行的。对吗？

谢谢，

本

编辑：澄清一下，攻击者无权访问散列算法，因此他们无法向系统发送任何垃圾信息。他们所拥有的只是哈希，他们必须弄清楚它是如何编译的。当然，即使他们知道哈希是如何生成的，尝试用长盐暴力破解所有组合也会使其不切实际吗？

此外，哈希不是用户的密码或用户名，它只是用于身份验证的一组随机字符。所以不需要存储盐和随机数，只需存储生成的哈希即可。在这种情况下，上面的系统（用下面的代码表示）是否是一个很好的系统，可以防止攻击者能够真实地猜测用户的哈希值可能是什么？

我知道那只是 1000-9999 而不是上面提到的数十亿。

再次感谢。

我想知道是否有人可以详细解释一下，链如何在彩虹表中工作，就像你对一个完整的新手一样，但与编程相关。

我知道一个链长 16 个字节。8 个字节标记起点，8 个字节标记结束。我也知道在文件名中我们有链长度，即 2400。这意味着在我们的起点和终点之间只有 16 个字节，我们有 2400 个可能的明文，什么？这是如何运作的？在这 16 个字节中，我如何获得 2400 个哈希和明文，还是我误解了这一点？

非常感谢您的帮助。

谢谢。

PS：我已经阅读了相关论文并在谷歌上搜索了这个主题。我想我只是错过了一些重要的东西来让这些齿轮转动。

我最近获得了适用于 Windows 的 l0pht-CD，并在我的 PC 上试用了它，它可以工作！！

2600hertz.wordpress.com/2009/12/22/100-windows-xp-vista-7-password-recovery

• 我也读过 kestas.kuliukas.com/RainbowTables/

我正在设计一个以类似方式存储 pwd-s 的“登录模拟器”。当前的实现将容易受到上述攻击。请任何人都可以说明（尽可能简单地），如何加强对这样的彩虹桌攻击。

我的目标：构建“登录模拟器”以尽可能安全。（阅读黑客竞赛 ;-)）

谢谢你。