39

假设您可以自由决定如何将散列密码存储在 DBMS 中。像这样的计划有明显的弱点吗？

要创建存储在 DBMS 中的哈希值，请使用：

  • 作为 salt 的一部分对 DBMS 服务器实例唯一的值，
  • 而用户名作为盐的第二部分，
  • 并使用实际密码创建盐的串联，
  • 并使用 SHA-256 算法对整个字符串进行哈希处理，
  • 并将结果存储在 DBMS 中。

这意味着任何想要提出冲突的人都必须分别为每个用户名和每个 DBMS 服务器实例单独完成工作。我计划让实际的散列机制保持一定的灵活性，以允许使用仍在研究中的新NIST标准散列算法 ( SHA-3 )。

“DBMS 服务器实例独有的值”不必保密——尽管它不会随便泄露。目的是确保如果有人在不同的 DBMS 服务器实例中使用相同的密码，则记录的哈希值会有所不同。同样，用户名也不会是秘密的——只有正确的密码。

首先是密码，然后是用户名和“唯一值”，或者三个数据源的任何其他排列，会有什么好处吗？或者如何交错字符串？

我是否需要添加（并记录）随机盐值（每个密码）以及上述信息？（优点：用户可以重复使用密码，并且可能仍然会在数据库中记录不同的哈希值。缺点：必须记录盐。我怀疑优点远大于缺点。）

有很多相关的 SO 问题 - 这个列表不太可能是全面的：

我认为这些问题的答案支持我的算法（尽管如果您只是使用随机盐，那么“每个服务器的唯一值”和用户名组件就不那么重要了）。

4

4 回答 4

31

盐只需要随机且独特。它可以被自由地知道，因为它对攻击者没有帮助。许多系统会将纯文本盐存储在数据库中哈希密码旁边的列中。

盐有助于确保如果两个人（用户 A 和用户 B）碰巧共享相同的密码，这并不明显。如果没有每个密码的随机和唯一盐，哈希值将是相同的，显然如果用户 A 的密码被破解，那么用户 B 必须具有相同的密码。

它还有助于防止可以将哈希字典与已知密码匹配的攻击。例如彩虹桌。

此外，使用内置“工作因子”的算法也意味着随着计算能力的增加，算法创建散列所必须经过的工作也会增加。例如，bcrypt。这意味着蛮力攻击的经济学变得站不住脚。据推测，创建已知哈希表变得更加困难，因为它们需要更长的时间来创建；“工作因素”的变化意味着必须建立更多的表格。

于 2009-07-27T23:06:45.913 回答
19

我认为你把问题复杂化了。

从问题开始：

  1. 您是否正在尝试保护弱密码？
  2. 您是否正在尝试减轻彩虹攻击？

您提出的机制确实可以防止简单的彩虹攻击，因为即使用户 A 和用户 B 的密码相同，散列密码也会不同。确实，似乎是一种相当复杂的方法来对过于复杂的密码进行加盐。

  • 当您将数据库迁移到另一台服务器时会发生什么？
    • 您能否更改每个数据库的唯一值，如果可以，则可以生成全局彩虹表，如果没有，则无法恢复数据库。

相反，我只会添加额外的列并存储适当的随机盐。这将防止任何类型的彩虹攻击。跨多个部署。

但是，它不会保护您免受暴力攻击。因此，如果您试图保护密码错误的用户，您将需要寻找其他地方。例如，如果您的用户有 4 个字母的密码，即使使用盐和最新的哈希算法，它也可能在几秒钟内被破解。

于 2009-07-28T00:30:10.343 回答
7

我认为您需要问自己“您希望通过使这比仅生成随机盐值并存储它更复杂来获得什么？” 你的算法越复杂，你就越有可能无意中引入一个弱点。不管我怎么说，这可能听起来很刻薄，但它的意思是有帮助的——你的应用程序有什么特别之处以至于它需要一个花哨的新密码哈希算法？

于 2009-07-28T01:07:00.557 回答
6

为什么不在密码中添加一个随机盐并散列该组合。接下来将哈希和盐连接到单个字节 [] 并将其存储在数据库中？

随机盐的优点是用户可以自由更改其用户名。Salt 不必保密，因为它用于防止字典攻击。

于 2009-07-27T23:05:44.527 回答