假设您可以自由决定如何将散列密码存储在DBMS中 . 像这样的计划有明显的弱点吗？
要创建存储在DBMS中的哈希值，请执行以下操作：
-
作为salt的一部分，DBMS服务器实例唯一的值，
-
用户名作为盐的第二部分，
-
并使用实际密码创建salt的串联，
-
使用SHA-256算法散列整个字符串，
-
并将结果存储在DBMS中 .
这意味着任何想要发生冲突的人都必须分别为每个用户名和每个DBMS服务器实例单独完成工作 . 我打算保持实际的哈希机制有点灵活，以允许使用仍在使用的新的NIST标准哈希算法（SHA-3） .
“DBMS服务器实例独有的值”不一定是秘密的 - 尽管它不会随便泄露 . 目的是确保如果有人在不同的DBMS服务器实例中使用相同的密码，则记录的哈希值会有所不同 . 同样，用户名也不是秘密 - 只需要正确的密码 .
首先输入密码和第二个用户名和“唯一值”，或者三个数据源的任何其他排列是否有任何优势？或者交错字符串怎么样？
我是否需要添加（并记录）随机盐值（每个密码）以及上述信息？ （优点：用户可以重新使用密码，但仍然可能会在数据库中记录不同的哈希值 . 缺点：必须记录盐 . 我怀疑优势远大于缺点 . ）
有很多相关的SO问题 - 这个清单不太可能是全面的：
我认为这些问题的答案支持我的算法（尽管如果你只是使用随机盐，那么'每个服务器的唯一值'和用户名组件就不那么重要了） .
4 回答
盐只需要随机而独特 . 它可以自由地知道，因为它对攻击者没有帮助 . 许多系统会将纯文本salt存储在散列密码旁边的列中的数据库中 .
盐有助于确保如果两个人（用户A和用户B）碰巧共享相同的密码，则不明显 . 如果没有每个密码的随机和唯一的盐，则哈希值将是相同的，并且显然如果用户A的密码被破解，则用户B必须具有相同的密码 .
它还有助于防止哈希词典与已知密码匹配的攻击 . 例如彩虹桌 .
同样使用内置"work factor"的算法也意味着随着计算能力的增加，算法必须通过创建哈希的工作也可以增加 . 例如，bcrypt . 这意味着暴力攻击的经济学变得站不住脚 . 据推测，创建已知哈希表会变得更加困难，因为它们需要更长时间才能创建; "work factor"的变化将意味着必须建造更多的 table .
我认为你的问题太复杂了 .
从问题开始：
您是否在尝试保护弱密码？
您是否正在尝试减轻彩虹攻击？
您建议的机制可以防止简单的彩虹攻击，即使用户A和用户B具有SAME密码，散列密码也会不同 . 它确实是一种相当复杂的方法来腌制过于复杂的密码 .
将数据库迁移到另一台服务器时会发生什么？
是否可以更改每个DB的唯一值，如果是，则可以生成全局彩虹表，否则则无法恢复数据库 .
相反，我只需添加额外的列并存储适当的随机盐 . 这可以防止任何类型的彩虹攻击 . 跨多个部署 .
但是，它不会保护您免受暴力攻击 . 因此，如果您尝试保护具有蹩脚密码的用户，则需要查看其他地方 . 例如，如果您的用户有4个字母的密码，即使使用salt和最新的哈希算法，它也可能在几秒钟内被破解 .
我想你需要问自己“你想通过使这个更复杂而不仅仅是生成随机盐值并存储它来获得什么？”你制作算法越复杂，你就越有可能无意中引入一个弱点 . 无论我怎么说，这听起来都可能听起来很麻烦，但它的意思是有帮助的 - 你的应用程序有什么特别之处，它需要一个奇特的新密码散列算法？
为什么不在密码中添加随机盐并散列该组合 . 接下来将哈希和salt连接到单个字节[]并将其存储在D b？
随机盐的优点是用户可以自由更改其用户名 . Salt不一定要保密，因为它用于防止字典攻击 .