终极哈希保护 - 概念论

Question

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

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

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

所以，所有这一切都已知 - 让我们假设攻击者进入你的网站并获得一切，一切。那么你现在做什么？

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

让图像显示您的网站与其他95％的网站一样，用户数据 - 甚至是完全的服务器访问权限 - 都不值得蹲下。攻击者碰巧是在你的一个用户“Bob”之后，因为他知道“Bob”在你的网站上使用与银行网站上相同的密码。他也碰巧知道鲍勃在那里有他的人生储蓄。现在，如果攻击者可以破解我们的网站哈希，剩下的将是小菜一碟。

所以这是我的问题 - 如何在没有任何可追踪路径的情况下扩展密码的长度？或者，如何使哈希过程复杂化并及时复制？我唯一想到的就是你可以重新散列数千次哈希，并将创建最终彩虹表所花费的时间增加1000倍。这是因为攻击者在创建表时必须遵循相同的路径。

还有其他想法吗？

Answer 1

  

解决方案，使用用户salt来制作哈希   输入更复杂，超过50chars   他们永远无法做到   生成一个表（大的方式   大小的字符串）。另外，他们会的   必须为每个人创建一个新表   用户。问题：如果他们下载了db   他们将获得用户盐，所以你   如果他们关心的话，回到原点   够了。

这种推理是错误的。

彩虹表（一般字典攻击的具体实现）将空间换成时间。但是，生成字典（彩虹或其他）需要花费很多时间。只有当它可以用于多个哈希时才值得。盐防止这种情况。盐不需要保密，只需要给定密码不可预测。这使得攻击者拥有为该特定盐生成的字典的机会可忽略不计。

Answer 2

  

“我唯一想到的就是你可以重新散列哈希数千次，并将创建最终彩虹表所花费的时间增加1000倍。”

这不就是基于Blowfish的BCrypt哈希的含义吗？增加计算哈希所需的时间，以便强力破解（和彩虹表创建）变得可撤销？

  

“我们提出两种算法具有适应性成本（...）”

有关适应性成本哈希算法的更多信息：http://www.usenix.org/events/usenix99/provos.html

Answer 3

如何采用“胡椒”的想法并在专用于散列密码的单独服务器上实现它 - 并锁定除了这一个简单且安全的服务之外 - 甚至可能使用速率限制来防止滥用。使攻击者无法克服，要么获得对此服务器的访问权限，要么对胡椒，自定义RNG和明文扩展算法进行逆向工程。

当然，如果他们能够访问一切，他们可以在一段时间内对用户活动进行精确定位..

Answer 4

嗯......好吧，我接受了这个：

• 您无法从哈希中获取原始密码。我有你的哈希，我可能会找到一个适合该哈希的密码，但是我无法登录到使用此密码的任何其他网站，假设它们都使用了salting。这里不是没有真正的问题。
• 如果有人拿到您的数据库甚至您的网站来获取您的配置，那么无论如何都会被搞砸。
• 对于管理员或其他超级帐户，实施第二种验证方式，即限制登录到某些IP范围，使用客户端SSL证书等。
• 对于普通用户，您将没有太多机会。你用密码做的一切都需要存放在一些配置或数据库中，所以如果有你的网站，我也有你的魔术蛇油。
• 强密码限制并不总是有效。有些网站要求密码具有数字字符 - 因此，大多数用户将1添加到他们通常的密码中。

所以我不完全确定你想要在这里实现什么？在用户密码的前面添加Salt并使用第二种身份验证保护管理员帐户似乎是最好的方法，因为用户根本不选择正确的密码而且不能强制使用。

Answer 5

我希望有人可能有解决方案，但遗憾的是，当我第一次发布问题时，我并没有好转。似乎没有什么可以做的，只是找到一个耗时的算法或重新散列1,000次，以减慢生成彩虹表（或强制执行）散列的整个过程。