使用Rfc2898DeriveBytes从明文密码创建安全密码时盐的重要性

时间:2013-12-11 21:22:38

标签: security encryption passwords cryptography salt

我想在我的一个C#.NET应用程序中加入和解密文件。场景很简单:用户A向用户B发送AES256加密文件。明文密码在不同的频道上交换(例如电话或其他)。

根据我的理解,我应该使用Rfc2898DeriveBytes将用户的明文密码转换为更安全的密码,使用10,000轮。 (见this article)。

我不明白盐在我的场景中的作用。通常在散列密码中使用salt来防止字典攻击。但在我的场景中,PBKDF2算法用于通过添加PBKDF2轮所需的额外计算来弥补短或易猜测的明文密码的弱点。

如果我选择随机盐,那么接收器也需要知道该盐才能正确解密。如果我使用恒定的盐,那么黑客可以轻松地对我的代码进行逆向工程并使用我的恒定盐进行暴力攻击(尽管由于PBKDF2迭代它们会非常慢)。

根据我的理解,我别无选择,只能在我的场景中使用恒定盐,并强制执行一个良好的明文密码规则,以弥补恒定盐的弱点。我的假设是否正确?

2 个答案:

答案 0 :(得分:5)

在密码散列(和密钥派生)的上下文中,Salts用于防止像彩虹表这样的预计算攻击。

请注意,每个密码的盐必须不同且不可预测(最好是随机的)。另请注意,盐不需要保密 - 这就是密码的含义。保持盐的秘密,你无法获得安全保障。

在您的情况下,建议的方法是每次加密文件时生成随机盐,并将盐与密文一起传输。

顺便提一下,您是否有使用AES-256的具体原因?由于额外的轮次,它比AES-128慢约40%,并且它没有实际的安全优势(特别是在基于密码的加密的情况下)。

使用像PGP这样成熟的标准而不是从加密原语构建自己的协议也是值得考虑的,因为构建安全协议非常困难,甚至专家也不总能做到正确。

答案 1 :(得分:0)

你的假设是正确的。如果他们可以访问密码,他们也可以访问盐。我见过的BCrypt实现将迭代次数,哈希值和salt都放在同一个结果字符串中!

这个想法是:即使已知迭代次数的盐和数字,您的哈希也应该是安全的。 (如果我们总能知道攻击者不知道盐和迭代次数甚至算法,安全性会变得更加容易!在攻击者礼貌地拒绝阅读我们的盐之前,我们必须假设他们可以访问如果他们有一些超级计算机和几百万年的计算时间可供他们使用,那么他们是对的,他们可以强行对待他们。