密码哈希值,盐值和哈希值的存储

假设您可以自由决定如何将密码散列存储在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立更多的表格。

我认为你过分复杂的问题。

从问题开始:

  1. 你想保护弱密码吗?
  2. 你想减轻彩虹攻击吗?

您提出的机制可以防止简单的彩虹攻击,即使用户A和用户B拥有相同的密码,哈希密码也会不同。 它似乎是一个相当复杂的方法来腌制一个过于复杂的密码。

  • 将数据库迁移到另一台服务器时会发生什么?
    • 你可以改变独特的,每个数据库的价值,如果是这样一个全球彩虹表可以生成,如果不是,那么你不能恢复你的数据库。

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

但是,它不会保护你免受暴力攻击。 所以,如果你想保护那些有蹩脚密码的用户,你需要去其他地方看看。 例如,如果您的用户有4个字母的密码,那么即使使用salt和最新的散列algorithm,也可能在几秒钟内破解。

我认为你需要问自己:“你希望通过制造这个更复杂的东西,而不是仅仅产生一个随机的盐值并存储它来获得什么? 你做algorithm越复杂,你越可能不经意地引入一个弱点。 不pipe怎么说,这听起来可能都很糟糕,但它的含义很有帮助 – 你的应用程序有什么特别的地方,它需要一个新的密码哈希algorithm?

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

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