是否有安全专家推荐 bcrypt 用于密码存储?

信息安全 密码 密码学 哈希 bcrypt
2021-08-21 21:17:42

从表面上看,bcrypt 是Niels Provos和 David Mazieres 为哈希密码设计的一个 11 年历史的安全算法,它基于 NIST 批准的河豚算法中使用的初始化函数,似乎好得令人难以置信。它不容易受到彩虹表的攻击(因为创建它们的成本太高),甚至不容易受到暴力攻击。

然而 11 年后,许多人仍在使用带盐的 SHA2x 来存储密码哈希,而 bcrypt 并未被广泛采用。

  • NIST 关于 bcrypt(和一般的密码散列)的建议是什么?
  • 著名的安全专家(如 Arjen Lenstra 等)对使用 bcrypt 进行密码散列有何看法?
4个回答

Bcrypt拥有加密算法所能达到的最好的声誉:它已经存在了相当长的一段时间,使用相当广泛,“引起了人们的注意”,但迄今为止仍然没有被破坏。

为什么 bcrypt 比 PBKDF2 好一些

如果您详细查看情况,您实际上可以看到 bcrypt 比PBKDF2更好的一些点。Bcrypt 是一种密码散列函数,旨在降低速度。准确地说,我们希望密码散列函数对于攻击者来说尽可能慢,而对于诚实的系统来说不要太慢由于“诚实的系统”倾向于使用现成的通用硬件(即“PC”),攻击者也可以使用这些硬件,我们希望的最好结果是让攻击者和攻击者的密码散列速度慢N倍。为了我们。然后我们调整N以免超出我们的资源(其中最重要的是用户的耐心,这是非常有限的)。

我们要避免的是,攻击者可能会使用一些非 PC 硬件,这将使他比我们受到 bcrypt 或 PBKDF2 隐含的额外工作的影响更少。特别是,勤奋的攻击者可能想要使用GPUFPGA例如,SHA-256 可以在 GPU 上非常有效地实现,因为它只使用 GPU 非常擅长的 32 位逻辑和算术运算。因此,与价值 500 美元的 PC 相比,拥有价值 500 美元 GPU 的攻击者每小时可以“尝试”更多的密码(比率取决于 GPU 的类型,但 10 倍或 20 倍的比率会是典型的)。

Bcrypt 恰好严重依赖对在整个算法执行过程中不断更改的表的访问。这在 PC 上非常快,在 GPU 上就更不用说了,GPU 内存是共享的,所有内核都在竞争对内部内存总线的控制。因此,与攻击者使用 PBKDF2 或类似设计所获得的提升相比,攻击者从使用 GPU 获得的提升要小得多。

bcrypt 的设计者非常清楚这个问题,这就是为什么他们使用分组密码Blowfish而不是 SHA-* 函数来设计 bcrypt。他们在文章中指出:

这意味着人们应该使任何密码功能尽可能高效地用于其将在其中运行的设置。crypt 的设计者没有做到这一点。他们基于 DES 加密,这是一种在软件中实现的效率特别低的算法,因为有许多位转置。他们不考虑硬件攻击,部分原因是无法使用库存 DES 硬件计算加密。不幸的是,Biham 后来发现了一种称为位切片的软件技术,它消除了计算许多同时 DES 加密时的位转置成本。虽然位切片不会帮助任何人更快地登录,但它为暴力密码搜索提供了惊人的加速。

这表明硬件及其使用方式很重要。即使使用与诚实系统相同的 PC,攻击者也可以使用位切片并行尝试多个密码并从中获得提升,因为攻击者多个密码可以尝试,而诚实系统一次只有一个。

为什么 bcrypt 不是最安全的

bcrypt 的作者在 1999 年工作。当时,威胁是门数非常少的定制ASIC 。时代变了;现在,老练的攻击者将使用大型 FPGA,并且较新的模型(例如 Xilinx 的 Virtex)具有嵌入式 RAM 块,这使他们能够非常有效地实现 Blowfish 和 bcrypt。Bcrypt 只需要 4 kB 的快速 RAM。虽然 bcrypt 在让 GPU 增强型攻击者的生活变得困难方面做得不错,但它对使用 FPGA 的攻击者几乎没有作用。

这促使 Colin Percival在 2009 年发明了scrypt 。这是一个类似 bcrypt 的函数,需要更多的 RAM。这仍然是一个新设计(仅两年),远没有 bcrypt 那样普及;我认为它太新了,不能在一般基础上推荐。但它的事业应该被追随。

编辑: scrypt 并没有完全兑现它的承诺。基本上,它有利于它的设计目的,即保护计算机主硬盘的加密密钥:这是一个使用上下文,其中散列可以使用数百兆的 RAM 和几秒钟的 CPU。对于验证传入请求的繁忙服务器来说,CPU 预算要低得多,因为服务器需要能够同时处理多个并发请求,并且不减慢速度在偶尔的峰值负载下爬行;但是当 scrypt 使用较少的 CPU 时,它也使用较少的 RAM,这是函数内部定义的一部分。当哈希计算必须在工作的几毫秒内完成时,使用的 RAM 量为如此之低,以至于 scrypt 在技术上变得比 bcrypt 更弱。)

NIST 的建议

NIST 发布了关于存储散列密码的特别出版物 SP 800-132 。基本上他们推荐PBKDF2。这并不意味着他们认为 bcrypt 不安全;他们对 bcrypt 只字未提。这只是意味着 NIST 认为 PBKDF2 “足够安全”(而且它肯定简单的哈希好得多!)。此外,NIST 是一个行政组织,因此他们一定会喜欢任何基于 SHA-256 等已经“批准”的算法的东西。另一方面,bcrypt 来自从未接受过任何 NIST 祝福(或诅咒)的 Blowfish。

虽然我推荐 bcrypt,但我仍然遵循 NIST,如果您实现 PBKDF2 并正确使用它(具有“高”迭代次数),那么密码存储很可能不再是您的安全问题中最糟糕的问题。

bcrypt 与简单的加盐 SHA-256 哈希相比具有显着优势:bcrypt 使用修改后的密钥设置算法,该算法非常昂贵。这称为密钥强化,并使密码更安全地抵御暴力攻击,因为攻击者现在需要更多时间来测试每个可能的密钥。

在我个人建议您阅读的名为“彩虹表足够了:您需要了解的有关安全密码方案的知识”的博客文章中,作者兼安全研究员 Thomas Ptacek 推荐使用 bcrypt。

就个人而言,我最近一直在研究PBKDF2,它是一个密钥派生函数,它将伪随机函数(例如加密哈希)与盐一起应用于输入密码,然后通过重复该过程多次得出一个密钥作为指定。虽然它是一个密钥派生函数,但它在其核心使用密钥强化原理,这是您在决定如何安全地生成密码哈希时应该努力的众多事情之一。

引用上述链接帖子中的 Thomas Ptacek 的话:

速度正是您在密码哈希函数中不想要的。

我认为 Gui 关于 PBKDF2 的建议是有价值的,尽管我知道 Rook 强烈反对。要是他们清楚自己的推理就好了!

无论如何,与 HMAC-SHA256 相比,没有理由使用加盐的 SHA-256 哈希。HMAC 具有阻止扩展攻击的优势。

NIST 是一家美国政府组织,因此遵循 FIPS(美国)标准,该标准不包括河豚,但包括 SHA-256 和 SHA-512(甚至针对非数字签名应用程序的 SHA-1,甚至在 NIST SP800-131A 中,它描述了每个旧算法可以用于什么目的的时间)。

对于任何需要遵守美国 NIST 或 FIPS 标准的企业,bcrypt 不是一个有效的选择。当然,如果您在那里开展业务,请分别查看每个国家的法律法规。

PBKDF2 很好;真正的诀窍是在诚实的服务器上安装 Tesla(基于 GPU)的卡,这样迭代次数就可以足够高,以与基于 GPU 的破解者竞争。对于 2012 年的 PBKDF2,OWASP建议在其密码存储备忘单上至少进行 64,000 次迭代,每 2 年翻一番。