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

Question

假设您可以自由决定将散列密码存储在DBMS中的方式。这样的计划是否存在明显的弱点？

要创建存储在DBMS中的哈希值，请执行以下操作：

作为盐一部分的DBMS服务器实例唯一的值，

用户名是盐的第二部分，

并使用实际的密码创建盐的串联，

然后使用SHA-256算法对整个字符串进行哈希处理，

并将结果存储在DBMS中。

这意味着任何想解决冲突的人都必须分别为每个用户名和每个DBMS服务器实例分别进行工作。我打算使实际的哈希机制保持一定的灵活性，以允许使用仍在开发中的新的NIST标准哈希算法（SHA-3）。

“ DBMS服务器实例唯一的值”不必是秘密的-尽管不会随意泄露。目的是确保如果有人在不同的DBMS服务器实例中使用相同的密码，则记录的哈希值将不同。同样，用户名也不会是秘密的-仅是正确的密码。

首先使用密码，然后使用用户名和“唯一值”，或者对这三个数据源进行任何其他排列，会有任何好处吗？或交织字符串呢？

我是否需要添加（并记录）随机盐值（每个密码）以及上述信息？（优点：用户可以重复使用密码，并且很可能仍然在数据库中记录了一个不同的哈希值。缺点：必须记录盐。我怀疑优点远大于缺点。）

密码哈希：固定长度的二进制字段还是单个字符串字段？

我认为这些问题的答案支持我的算法（尽管如果您只是使用随机盐，那么“每台服务器的唯一值”和用户名组件就不太重要了）。

Answer 1

盐只需要是随机且唯一的。由于它对攻击者无济于事，因此可以自由地知道它。许多系统会在哈希密码旁边的列中的数据库中存储纯文本盐。盐有助于确保两个人（用户A和用户B）碰巧共享同一密码，这种情况并不明显。如果没有每个密码的随机唯一盐，则哈希值将相同，并且显然，如果用户A的密码被破解，则用户B必须具有相同的密码。它还可以防止哈希字典可以与已知密码匹配的攻击。例如彩虹桌。同样，使用内置“工作因数”的算法也意味着随着计算能力的提高，创建散列所必须经过的算法也可以增加。例如，bcrypt。这意味着暴力攻击的经济学变得难以为继。据推测，创建已知哈希表将变得更加困难，因为它们需要花费更长的时间来创建。“工作因子”的变化将意味着必须建立更多的表。

Answer 2

我认为您使问题复杂化了。从问题开始：您是否要保护弱密码？您是否要缓解彩虹攻击？您提出的机制确实可以防止彩虹攻击，即使用户A和用户B具有相同的密码，哈希密码也将有所不同。确实，给密码添加盐过于复杂，这似乎是一种相当复杂的方法。将数据库迁移到另一台服务器时会发生什么？您是否可以更改每个数据库的唯一值，如果可以，那么可以生成全局彩虹表，如果不能，则无法还原数据库。相反，我只需要添加额外的列并存储适当的随机盐即可。这将防止任何形式的彩虹攻击。跨多个部署。但是，它不能保护您免受暴力攻击。因此，如果您尝试保护密码不正确的用户，则需要在其他地方查找。例如，如果您的用户具有4个字母的密码，即使使用盐和最新的哈希算法，也可能在几秒钟内破解它。

Answer 3

我认为您需要问自己：“与仅生成随机盐值并将其存储起来相比，使其变得更加复杂，您希望从中获得什么？” 您使算法变得越复杂，就越有可能不经意地引入弱点。不管我怎么说，这听起来都比较老套，但这很有帮助-您的应用程序有什么特别之处，以至于它需要一种新颖的密码哈希算法？