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