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

要创建存储在DBMS中的哈希值，请执行以下操作：

• 作为salt的一部分，dbms服务器实例唯一的值，
• 用户名作为salt的第二部分，
• 创建salt与实际密码的连接，
• 并使用sha-256算法散列整个字符串，
• 并将结果存储在DBMS中。

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

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

首先使用密码，其次使用用户名和"唯一值"，或者对三个数据源进行任何其他排列，有什么好处吗？或者交错的字符串呢？

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

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

• 在数据库中加密/散列纯文本密码
• PHP密码的安全哈希和salt
• 把盐藏起来做土豆泥的必要性
• 客户端MD5哈希和时间盐
• 简单密码加密
• 制盐和开源软件
• 密码哈希：固定长度的二进制字段还是单字符串字段？

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

盐只是需要随机的和独特的。它可以自由地称为它对攻击者没有帮助。许多系统将把纯文本salt存储在数据库中哈希密码旁边的列中。

salt有助于确保如果两个人(用户A和用户B)恰好共享同一个密码，则不明显。如果没有每个密码的随机和唯一salt，散列值将是相同的，显然，如果破解了用户A的密码，那么用户B必须具有相同的密码。

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

此外，使用内置"工作因子"的算法也意味着，随着计算能力的增加，算法必须完成的创建散列的工作也会增加。例如，bcrypt。这意味着暴力攻击的经济性变得无法维持。可能创建已知哈希表会变得更加困难，因为创建这些哈希表需要更长的时间，"工作因子"的变化意味着需要创建更多的表。

我觉得你把问题弄得太复杂了。

从问题开始：

您建议的机制确实可以防止简单的彩虹攻击，因为即使用户A和用户B拥有相同的密码，哈希密码也会有所不同。确实如此，似乎是一个相当复杂的加盐密码方法。

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

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

但是，它不会保护你免受蛮力攻击。所以，如果你试图保护那些密码糟糕的用户，你就需要找别的地方。例如，如果您的用户有4个字母的密码，即使使用salt和最新的哈希算法，也可能在几秒钟内破解。

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

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

随机salt的优点是用户可以自由更改其用户名。盐不一定是秘密的，因为它是用来防止字典攻击的。