密码散列、salt和散列值的存储

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

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

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

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

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

从问题开始:

1. 您是否试图保护弱密码?
2. 你想减轻彩虹攻击吗?

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

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

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

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

我认为你需要问自己,“你希望通过使这比生成随机的盐值并存储它更复杂来获得什么?”你的算法越复杂,你越可能无意中引入一个弱点。不管我怎么说,这可能听起来很难听,但这是有帮助的——你的应用程序有什么特别的地方需要一个新的密码哈希算法?

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

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