密码散列,盐和散列值的存储

Question

假设您可以自由决定如何将散列密码存储在DBMS中.像这样的计划有明显的弱点吗？

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

这意味着任何想要发生冲突的人都必须分别为每个用户名和每个DBMS服务器实例单独完成工作.我打算保持实际的哈希机制有点灵活,以允许使用仍在使用的新NIST标准哈希算法(SHA-3).

"DBMS服务器实例独有的值"不一定是秘密的 - 尽管它不会随便泄露.目的是确保如果有人在不同的DBMS服务器实例中使用相同的密码,则记录的哈希值会有所不同.同样,用户名也不是秘密 - 只需要密码.

首先使用密码以及用户名和"唯一值"第二个,或三个数据源的任何其他排列是否有任何优势？或者交错字符串怎么样？

我是否需要添加(并记录)随机盐值(每个密码)以及上述信息？(优点:用户可以重新使用密码,但仍然可能会在数据库中记录不同的哈希值.缺点:必须记录盐.我怀疑其优势远大于缺点.)

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

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

Answer 1

盐只需要随机而独特.它可以自由地知道,因为它对攻击者没有帮助.许多系统会将纯文本salt存储在散列密码旁边的列中的数据库中.

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

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

同样使用内置"工作因子"的算法也意味着随着计算能力的增加,算法必须经历以创建哈希的工作也可以增加.例如,bcrypt.这意味着暴力攻击的经济学变得站不住脚.据推测,创建已知哈希表会变得更加困难,因为它们需要更长时间才能创建; "工作因素"的变化将意味着必须建立更多的表格.

这个答案是对的.盐的目的是*不*所以"共享密码不明显".目的是使字典攻击更加困难.(允许将此类危险错误的错误标记为"答案",这是该网站的致命设计缺陷.) (13认同)
Salting还可以保护我们免受基于彩虹表的攻击 (5认同)
@ColinMackay我建议您阅读http://codahale.com/how-to-safely-store-a-password/,了解您的答案为什么会出现危险错误.它的长短不一,"蛮力比你想象的要快".拥有盐是必要的 - 没有它人们可以只使用预先计算的查找表 - 但不足以保护使用弱密码的用户(大多数都是这样). (3认同)
@btilly您提供的链接是纯粹的(危险的)bunkum.bcrypt在防止暴力攻击方面不比使用密码更有效.攻击者的目的是获取访问权限.因此,他需要做的就是强制使用可能的密码,而不是哈希.bcrypt替代方案将计算费用转移到服务器,因此浪费资源,仅此而已.如果您使用密码12345并且我强行使用该密码,无论您使用什么奇怪的计算昂贵的加密技术,您都会被证明.随机盐就好了,不允许弱密码! (3认同)

Answer 2

我认为你的问题太复杂了.

从问题开始:

您建议的机制可以防止简单的彩虹攻击,即使用户A和用户B具有SAME密码,散列密码也会不同.它确实是一种相当精细的方法来腌制过于复杂的密码.

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

但是,它不会保护您免受暴力攻击.因此,如果您尝试保护具有蹩脚密码的用户,则需要查看其他位置.例如,如果您的用户有4个字母的密码,即使使用salt和最新的哈希算法,它也可能在几秒钟内被破解.

Answer 3

我想你需要问自己"你想通过使这个更复杂而不仅仅是生成一个随机盐值并存储它来获得什么？" 你制作算法越复杂,你就越有可能无意中引入一个弱点.无论我怎么说,这听起来都可能听起来很麻烦,但它的意思是有帮助的 - 你的应用程序有什么特别之处,需要花哨的新密码散列算法？

Answer 4

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

随机盐的优点是用户可以自由更改其用户名.Salt不一定要保密,因为它用于防止字典攻击.