KDF盐业:它是如何/什么时候可以公开？

Question

Post结构：

1. 先验源材料研究
2. 问题与细节
3. 假定威胁模型
4. 示例
5. 假设
6. 澄清

Prior源材料研究

0.1。RFC 2898

0.2。应用密码学手册

0.3.密码101

0.4.SE答案(例如：如果攻击者知道和和哈希，那么如何有效？)和(使用盐散列密码)

0.5 2018年DBIR

问题：

使用已知的salt和低熵密码的KDF比所谓的“完全破坏，一点也不安全”的原始哈希和salt更安全吗？

1.1详情：

根据现有的主题材料，KDF盐不需要保密。

在威胁模型中，推荐是否意味着用户提供的密钥/密码始终具有足够高的熵，或者不会是弱熵的实例？还是建议只适用于同一或不同的数据每次使用不同的salt/key定期加密的特定情况？Crypto101的作者写到了这篇关于通用密码哈希原语的文章：“虽然对每个用户使用不同的盐类可以防止这种情况发生，但使用带有每个用户盐的加密散列的系统今天仍然被认为是根本失效的；它们只是更难破解，但根本不安全。”

如果威胁模型总是假设用户提供的秘密密钥可能是弱的，那么使用带有已知盐的KDF比前面提到的使用带有未知(高熵)盐类的散列原语更安全吗？(这里有一个明显的计数器的答案请参见澄清)

问题的Assumed威胁模型：

2.1用户创建一个低熵密码(TW37VE)，该密码需要存储，并用于登录。2.2威胁参与者将使用相同的kdf (使用正确猜测的迭代)从这个常见的低熵密码中计算密钥。2.3盐类需要在用户提供的密码中增加熵(编辑:最初声明的“秘密密钥”而不是这里的密码) --假设是来自低熵空间--将在这里假定威胁行为者(根据文档中的建议)知道。2.4 KDF的慢计算/高内存开销是可以承受的，即使只访问单个用户数据也是如此:例如，它可能是一个内部威胁参与者愿意为特定用户访问数据的情况。2.5内部/内部威胁行为体:根据2018年DBIR，28%的报告数据泄露涉及内部/内部行为者。因此，即使在没有外部威胁的情况下，威胁模型也将内部行为者视为潜在威胁。因此，也需要确保盐的安全。(关于对显而易见的计数器的答复，请参见澄清)

示例：

使用的KDF：

对于密码TW37VE，PBKDF2_SHA256生成一个带有随机盐分0CE@N和100000次迭代的密钥，因此派生的密钥是：

kdf(TW37VE，0CE@N's，100000)：pbkdf2 2-sha256100000OCE@N‘s$！@#%^&

威胁KDF: kdf(捕获-弱密码= TW37VE，非秘密-salt=0CE@N，猜测-迭代= 100000)：

pbkdf2 2-sha256100000OCE@N的$！@#%^&

如果合法用户可以使用已知的低熵密码和检索到的盐类来验证自己，那么如果攻击者配备了(a)获取的密码(或预先计算过的字典/彩虹散列)和(b)非保密的盐，那么会有什么威慑作用呢？

即使威胁参与者扫描并匹配密码，比如64位的salt密钥空间也是微不足道的，由此产生的潜在延迟也不会受到影响。

问题中的Assumptions：

4.1。导出密钥的非随机部分与安全模型的强度无关。4.2。攻击者还可以使用pbkdf2-sha256和已知的盐分、获取的密钥和正确的猜测。

<#>澄清

5.1使用某些基于原语的方法的缺点是可以理解的；随机盐KDF在区分相似内容方面的优点也是如此。5.2问题的重点是为什么在假定的威胁模型下基于原始模式的模式被认为是被打破的，而KDF模式仅仅是在类似的条件下产生类似的威胁模型被认为是对前者的一种改进。5.3 DBIR报告说，"28%的内部参与者“的数字包括具有不同行为的不同类型的参与者，在这种情况下--尽管可能很小--被认为是应用程序的开发人员--服务器团队变流氓了(或者可能总是很糟糕？)。5.4土生土长的卷:有一种方法可以使盐类加密，而不需要威胁参与者访问盐解密密钥，除非整个数据库服务器被破坏。

摘要：

重申一下，当暴露kdf盐时，如何不让kdf盐成为一种秘密帮助，它可能是有害的，安全--相当于一个不安全的原始方法？

Answer 1

使用已知的salt和低熵密码的KDF比所谓的“完全破坏，一点也不安全”的原始哈希和salt更安全吗？

基于密码的散列或基于密码的密钥派生函数(PBKDF)更安全，因为它还使用了键拉伸技术(工作因子或迭代计数)，使对手更难以“猜测”密码。这些函数可能是内存，很难使对手更难攻击密码。由于工作因素只增加了一个恒定的时间因素，它提供的保护仍然是有限的。

请注意，这是特殊的基于密码的KDF。也有KBKDF的，如HKDF，可以使用盐，但不提供键拉伸。

如果威胁模型总是假设用户提供的秘密密钥可能是弱的，那么使用带有已知盐的KDF比前面提到的使用带有未知(高熵)盐类的散列原语更安全吗？(这里有一个明显的计数器的答案请参见澄清)

用户不提供(对称)密钥，用户提供密码。用户输入16字节二进制值是出了名的错误。

“秘密盐”也叫胡椒粉。如果可以保留一个秘密胡椒粉，那么是的，这将比使用盐更安全，即使盐是在PBKDF中使用的。如果胡椒值对于多个用户是相同的，那么您仍然应该使用额外的salt；否则，具有相同密码的用户将很容易识别。

Generally假设没有安全的密钥存储，所以使用胡椒是不可行的。显然，胡椒不能仅仅作为明文存储在同一个数据库中。

由于KDF为密码和salt提供了显式输入(但遗憾的是，对于单独的salt和key )，如果只是在散列之前对输入进行清晰的分离，则使用基于密钥的KDF或PBKDF的迭代次数为1的方法仍然比使用加密散列更好。

例如，\text{Hash}(P_0P_1\|S_0)和\text{Hash}(P_0\|S_0S_1)可以散列到相同的值，而\text{KDF}(P_0P_1, S_0)和\text{KDF}(P_0, S_0S_1)则不期望这一点。

Answer 2

salt的目的并不是使从密码中计算密钥变得更加困难。其目的是使其独一无二，即使多个用户共享相同的密码。

如果1000个用户共享密码"password1“，并且没有salt，那么访问密码散列数据库的攻击者只需对其中一个用户进行正确的猜测，其余的散列都是相同的。

如果1000个用户共享密码"password1“，并且每个用户都有一个唯一的salt，那么访问密码数据库的攻击者必须对每个用户进行正确的猜测，所有散列都是唯一的。因此，攻击者获得所有用户的散列要困难1000倍。为任何一个用户获取哈希的难度并没有改变。

盐类用于防止攻击者访问哈希密码的整个数据库。他们已经有了数据库访问权，所以他们也可以访问存储在服务器上的任何秘密值。特别是由于服务器需要访问这些秘密，以便计算用户登录时的密码散列。假设你能保守秘密，这违反了威胁模型的假设，因此不值得考虑。如果您能够可靠地将机密保存在服务器上，那么您最好将整个密码数据库存储在服务器上，而不必担心盐类。