密码哈希值，盐值和哈希值的存储
假设您可以自由决定如何将密码散列存储在DBMS中。 像这样的计划有明显的弱点吗？
要创建存储在DBMS中的散列值，请执行：
这意味着任何想要碰撞的人都必须分别为每个用户名和每个DBMS服务器实例分别完成工作。 我打算保持实际的散列机制的灵活性，以允许使用仍在使用的新NIST标准散列算法（SHA-3）。
'DBMS服务器实例独有的价值'不一定是秘密 - 尽管它不会随便泄露。 目的是确保如果某人在不同的DBMS服务器实例中使用相同的密码，则记录的散列值将会不同。 同样，用户名也不会是秘密 - 只是密码本身。
密码优先，用户名和“唯一值”第二，或三个数据源的其他排列是否有优势？ 或者交叉字符串呢？
我是否需要添加（并记录）随机盐值（每个密码）以及上面的信息？ （优点：用户可以重新使用密码，并且可能会在数据库中记录不同的哈希值。缺点：盐必须被记录下来，我认为这样做的好处远远大于缺点。）
有相当多的相关SO问题 - 这个列表不太可能是全面的：
我认为这些问题的答案支持我的算法（尽管如果你只是使用随机盐，那么'每个服务器的唯一值'和用户名组件就不那么重要了。
盐只需要是随机的和独特的。 它可以自由知道，因为它不会帮助攻击者。 许多系统会将纯文本salt存储在数据库中散列密码旁边的列中。
盐有助于确保如果两个人（用户A和用户B）碰巧共享相同的密码，则不明显。 没有每个密码的随机和唯一的盐值，散列值将是相同的，显然如果用户A的密码被破解，则用户B必须具有相同的密码。
它还有助于防止可以将哈希字典与已知密码进行匹配的攻击。 如彩虹桌。
同样使用内置“工作因子”的算法也意味着随着计算能力的增加，算法必须经历的工作才能创建哈希值也可以增加。 例如，bcrypt。 这意味着暴力攻击的经济性变得站不住脚。 据推测，创建已知哈希表的时间变得更加困难，因为它们需要更长的时间才能创建。 “工作因素”的变化意味着需要建立更多的表格。
我认为你过分复杂化了这个问题。
从问题开始：
您提出的机制可以防止简单的彩虹攻击，即使用户A和用户B拥有相同的密码，哈希密码也会不同。 它看起来像是一个相当复杂的方法，可以腌制一个过于复杂的密码。
相反，我只需添加额外的列并存储适当的随机盐。 这可以防止任何形式的彩虹攻击。 跨多个部署。
但是，它不会保护你免受暴力攻击。 因此，如果您试图保护拥有蹩脚密码的用户，则需要查看其他地方。 例如，如果用户有4个字母的密码，即使使用salt和最新的散列算法，它也可能在几秒钟内破解。
我想你应该问自己：“你希望通过制造这个更复杂的东西而不是仅仅产生一个随机盐值并存储它来获得什么？” 您制作算法越复杂，您越有可能无意中引入弱点。 无论我怎么说，这可能听起来都很尖锐，但它的含义很有帮助 - 你的应用程序有什么特别之处，它需要一个奇特的新密码哈希算法？
链接地址: http://www.djcxy.com/p/3667.html