security - 密码散列、盐和散列值的存储

Question

假设您可以自由决定如何将哈希密码存储在 DBMS 中。像这样的方案有明显的弱点吗？

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

• 作为盐一部分的 DBMS 服务器实例唯一的值，
• 用户名作为盐的第二部分，
• 并创建盐与实际密码的串联，
• 并使用 SHA-256 算法对整个字符串进行哈希处理，
• 并将结果存储在 DBMS 中。

这意味着任何想要解决冲突的人都必须分别为每个用户名和每个 DBMS 服务器实例单独完成这项工作。我计划让实际的哈希机制保持一定的灵 active ，以允许使用新的 NIST标准哈希算法 ( SHA-3 ) 仍在研究中。

“DBMS 服务器实例独有的值”不需要保密——尽管它不会被随意泄露。目的是确保如果有人在不同的 DBMS 服务器实例中使用相同的密码，记录的哈希值将会不同。同样，用户名也不会是 secret 的 - 只是正确的密码。

首先拥有密码，然后是用户名和“唯一值”，或者这三个数据源的任何其他排列是否有任何优势？或者交错字符串怎么样？

我是否需要添加(并记录)随机盐值(每个密码)以及上述信息？ (优点:用户可以重复使用密码，并且仍然可能获得数据库中记录的不同哈希值。缺点:必须记录盐。我怀疑优点远远超过缺点。)

有很多相关的问题 - 这个列表不太全面:

• Encrypting/Hashing plain text passwords in database
• Secure hash and salt for PHP passwords
• The necessity of hiding the salt for a hash
• Clients-side MD5 hash with time salt
• Simple password encryption
• Salt generation and Open Source software
• Password hashes: fixed-length binary fields or single string field?

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

Answer 1

盐只需是随机且唯一的。它可以被自由地知道，因为它对攻击者没有帮助。许多系统会将纯文本盐存储在数据库中哈希密码旁边的列中。

盐有助于确保如果两个人(用户 A 和用户 B)碰巧共享相同的密码，则不会很明显。如果每个密码没有随机且唯一的盐，则哈希值将相同，显然如果用户 A 的密码被破解，则用户 B 必须具有相同的密码。

它还有助于防止攻击，其中哈希字典可以与已知密码进行匹配。例如彩虹表。

此外，使用内置“工作因子”的算法还意味着，随着计算能力的增加，算法创建哈希所需的工作也会增加。例如，bcrypt 。这意味着暴力攻击的经济性变得站不住脚。据推测，创建已知哈希表会变得更加困难，因为创建它们需要更长的时间； “工作因素”的变化意味着必须构建更多的表。