但是11年后,许多人仍然使用带有盐的SHA2x来存储密码哈希和bcrypt没有被广泛采用。
NIST关于bcrypt(通常是密码散列)的建议是什么?
著名的安全专家(例如Arjen Lenstra等)对使用bcrypt进行密码哈希处理有何看法?
#1 楼
Bcrypt具有最好的密码算法声誉:它已经存在了很长一段时间,被广泛使用,“吸引了人们的注意”,但至今仍保持不变。为什么bcrypt比PBKDF2更好一些
如果仔细研究一下情况,实际上可以看到bcrypt比PBKDF2更好的地方。 Bcrypt是旨在降低速度的密码哈希功能。确切地说,我们希望密码散列函数对于攻击者尽可能慢,而对于诚实系统则不会令人难以忍受。由于“诚实的系统”倾向于使用现成的通用硬件(即“一台PC”),攻击者也可以使用它们,因此,我们希望最好的办法是使攻击者和用户的密码哈希速度都慢N倍。为我们。然后,我们调整N,以免超出资源(主要是用户的耐心,这确实是有限的)。
我们要避免的是攻击者可能会使用某些非PC硬件这将使他从bcrypt或PBKDF2隐含的额外工作中所受的痛苦比我们少。特别是,勤奋的攻击者可能想要使用GPU或FPGA。例如,SHA-256可以非常高效地在GPU上实现,因为它仅使用GPU擅长的32位逻辑和算术运算。因此,拥有价值500美元的GPU的攻击者每小时可以“尝试”更多的密码,这比拥有价值500美元的PC可以做到的多(密码的比率取决于GPU的类型,但是比率为10倍或20倍通常)。
Bcrypt严重依赖对表的访问,该表在整个算法执行期间会不断更改。这在PC上非常快,而在GPU上则更快,在GPU上共享内存,并且所有内核都争夺内部内存总线的控制权。因此,与使用PBKDF2或类似设计的攻击者相比,攻击者使用GPU所获得的提升大大降低了。
bcrypt的设计人员很清楚这个问题,这就是为什么他们从块密码Blowfish而不是SHA- *函数中设计bcrypt的原因。他们在文章中指出以下内容:这意味着应该对任何密码功能都尽可能有效地进行设置。 crypt的设计者未能做到这一点。他们基于DES的加密算法,由于许多位转置,因此在软件中实现效率极低。他们抵制了硬件攻击,部分原因是无法使用现有的DES硬件来计算加密。不幸的是,Biham随后发现了一种称为位片的软件技术,该技术消除了在计算许多同时进行的DES加密时的位转置成本。虽然分片并不能帮助任何人更快地登录,但是它提供了惊人的加速暴力破解密码的功能。
表明硬件及其使用方式非常重要。即使使用与诚实系统相同的PC,攻击者也可以使用位片并行尝试多个密码并加以利用,因为攻击者可以尝试多个密码,而诚实系统一次只能输入一个密码。 br />
为什么bcrypt不能达到最佳安全性
bcrypt的作者在1999年工作。当时,这种威胁是门数很少的定制ASIC。时代变了;现在,老练的攻击者将使用大型FPGA,而较新的模型(例如,Xilinx的Virtex)具有嵌入式RAM块,从而使它们可以非常有效地实现Blowfish和bcrypt。 Bcrypt仅需要4 kB的快速RAM。虽然bcrypt在使GPU增强的攻击者难以生存的过程中做得不错,但对使用FPGA的攻击者却无济于事。
这促使Colin Percival在2009年发明了scrypt。这是一个类似于bcrypt的函数,需要更多的RAM。这仍然是一个新设计(仅两年),其普及程度远不及bcrypt。我认为它太新了,不建议一般推荐。但是,它的职业生涯应该遵循。计算机的主硬盘:这是一种使用情况,其中哈希可以使用数百兆的RAM和价值几秒钟的CPU。对于繁忙的服务器,它对传入的请求进行身份验证时,CPU预算要低得多,因为服务器需要能够一次处理多个并发请求,并且在偶尔的峰值负载下不会减慢爬网速度;但是当scrypt使用更少的CPU时,它也使用更少的RAM,这是内部定义函数的一部分。计算必须在几毫秒的工作量内完成,使用的RAM数量如此之低,以致scrypt在技术上要比bcrypt弱。)
NIST的建议
关于存储哈希密码的主题的特殊出版物SP 800-132。基本上,他们推荐PBKDF2。这并不意味着他们认为bcrypt不安全;他们对bcrypt一无所获。这只是意味着NIST认为PBKDF2“足够安全”(并且肯定比简单的哈希好得多!)。而且,NIST是一个管理组织,因此它们必然会喜欢基于SHA-256之类已经“批准”的算法的任何事物。另一方面,bcrypt来自Blowfish,它从未收到过任何NIST的祝福(或诅咒)。 (具有“高”迭代次数),那么很有可能密码存储不再是最严重的安全问题。
评论
TL; DR:bcrypt比PBKDF2更好,因为使用GPU可以更好地加速PBKDF2。因此,PBKDF2可以更轻松地通过消费类硬件进行脱机暴力破解。
– Mikko Rantalainen
2012年7月5日,11:56
@EliCollins:我在这里很好奇-使用较高的迭代计数是否可以引入针对服务器的DDOS攻击?例如,如果我要同时向服务器发布数百次登录尝试,则尝试对所有密码进行哈希运算会立即使服务器不堪重负。有办法避免这种潜在问题吗?
–内森·奥斯曼(Nathan Osman)
13年4月7日,下午3:35
@GeorgeEdison避免DDOS在检查密码之前检查用户名。然后,如果该用户连续多次尝试登录失败(例如,其中10次失败),则拒绝密码,甚至不检查密码,除非该帐户已“冷却”几分钟。这样,一个帐户可以是DDOS帐户,而不是整个服务器帐户,并且即使没有非常强大的弱口令也无法在没有脱机攻击的情况下进行暴力破解。
–阿比·贝克特(Abhi Beckert)
13年7月22日在18:56
这个答案在2016年是最新的吗?例如,与PBKDF2,bcrypt等相比,Argon2(赢得了密码哈希竞赛)如何保持?由于这是一篇广为阅读的文章,因此最好定期查看此答案的更新,以重申其相关性或更新其建议。
– joshreesjones
16-2-18在3:38
@ThomasPornin我觉得Argon2上的一段将是这个已经很好的答案的最重要的部分。
–卢克公园
16-10-27在1:03
#2 楼
bcrypt相对于简单添加盐分的SHA-256哈希具有显着优势:bcrypt使用修改后的密钥设置算法,该算法非常昂贵。这称为密钥加强,它使密码对于暴力攻击更为安全,因为攻击者现在需要更多时间来测试每个可能的密钥。在博客文章“彩虹足够了”表:“您需要了解的有关安全密码方案的知识”,我个人建议您阅读,作者兼安全研究人员Thomas Ptacek建议使用bcrypt。
我个人一直最近查看了PBKDF2,它是一个密钥派生函数,它将伪随机函数(例如,密码哈希)与盐一起应用于输入密码,然后通过重复指定次数的过程来推导密钥。尽管它是密钥派生功能,但其核心使用密钥加强原理,这是在决定如何安全地生成密码哈希时应努力的许多事情之一。
要引用以上链接文章中的Thomas Ptacek:
密码哈希函数中,速度正是您所不想要的。
评论
bcrypt的基本假设是它运行缓慢,但这仅仅是一个假设,可能存在一个弱点,可以大大缩短执行时间,或者硬件演进可以绕过该慢点(与Scrypt相同)。另一方面,PKBDF依赖于经过良好测试的哈希,对于该哈希,已经存在相当快的近乎最佳的硬件,这意味着时间和复杂性参数是众所周知的(并且可以通过重复利用)。 PKBDF防御者确切地知道攻击者可以在一个数量级内做什么,而bcrypt防御者却不知道。
–埃里克·格兰奇
15年12月17日在11:28
@EricGrange:PKBDF防御者确实知道攻击者可以做什么。不幸的是,攻击者的执行速度至少比防御者快10到20倍。 Defender希望使用bcrypt,因为当前它似乎给攻击者以更少的优势。基本上,bcrypt的支持者认为,该算法似乎足以令人信任,并且可以使防御者和攻击者的竞争水平更高。如果您认为给攻击者至少10-20倍的性能提升是可以的,那么PKBDF是更好的选择,因为可以更好地了解折衷方案。
– Mikko Rantalainen
17年2月3日在10:16
@EricGrange对于所有算法都是如此。随着时间的流逝和更多的密码分析的完成,我们可以变得越来越有信心(但永远不能完全确定)特定算法没有特定的弱点。我们可以肯定地知道PBKDF2而不是bcrypt的风险的想法是荒谬的。
–vee_ess
17年11月30日在4:52
根据usenix.org/system/files/conference/woot14/woot14-malvoni.pdf的说法,使用定制硬件的攻击者的速度仅比使用通用i7 CPU的bcrypt防御器快2倍。似乎比攻击者要好得多,使用PKBDF的速度要比防御者快10到20倍。
– Mikko Rantalainen
18年7月4日在8:26
#3 楼
我认为Gui提出的有关PBKDF2的建议是值得的,尽管我知道Rook强烈不同意。除非他们清楚其理由!无论如何,与HMAC-SHA256相比,没有理由使用盐腌的SHA-256哈希。 HMAC具有阻止扩展攻击的优势。
评论
+1代表HMAC,我完全忘记提及HMAC,这是盐腌SHA-256哈希的更安全替代方案。长度扩展攻击是众所周知的。 Flickr API曾经遭到破坏,因为它曾经使用MD5(秘密+参数列表)对API调用进行签名(有关更多信息,请参见“ Flickr的API签名伪造漏洞” [PDF])
–朱塞佩·阿卡普托(Giuseppe Accaputo)
2010-09-18 10:50
HMAC与不可恢复的密码存储有何关系?
–好奇
2011年10月12日下午4:07
@curiousguy(迟来总比没有好...)通过使用密码作为HMAC密钥,并使用salt作为HMAC消息来计算HMAC,可以完成对盐散列的密码存储。这比天真地计算H(salt || password)更安全,尽管最好使用像bcrypt这样的实际密码哈希函数。
–SørenLøvborg
2013年6月12日12:51
@curiousguy HMAC是PBKDF2中最常用的PRF。因此,也不要使用裸HMAC。使用PBKDF2(带有HMAC-SHA256或HMAC-SHA512),bcrypt或scrypt。而已。不要发明或使用其他任何东西。自定义方案注定是错误的。这三个经过严格审查,易于使用。意识到PBKDF2最容易受到硬件加速字典攻击,而scrypt最不容易受到攻击。
–特雷尔(Terrel)缆车
2013年9月30日13:50在
#4 楼
NIST是总部位于美国的政府组织,因此遵循FIPS(美国)标准,该标准不包括河豚,但包括SHA-256和SHA-512(甚至包括用于非数字签名应用程序的SHA-1,甚至在NIST SP800-131A中进行了描述,其中描述了每种较旧的算法可以用于多长时间。)对于需要符合美国NIST或FIPS标准的任何业务,bcrypt都不是有效的选择。当然,如果您在当地开展业务,请分别检查每个国家的法律和法规。
PBKDF2很好;真正的诀窍是在诚实的服务器中获取Tesla(基于GPU)卡,以便可以使迭代足够高,以与基于GPU的破解程序竞争。对于2012年的PBKDF2,OWASP建议在其密码存储备忘单上至少进行64,000次迭代,每2年翻一番。
评论
在我看来,使用scrypt或bcrypt(更改软件)比向数百万台服务器添加昂贵的硬件(就前期成本和能源成本而言)要容易得多。在更高级别上,任何键扩展功能都只是尝试为密码添加更多的熵。如果(且仅当)密码足够强大以开头(例如,编码为10个diceware字的128位随机数),则PBKDF2的一次迭代就足够了。
–特雷尔(Terrel)缆车
2013年9月30日14:06
* crypt函数或PBKDF2的目的是将密码存储在非常难以找到原始密码的地方。它们不会使密码变得更强。 PBKDF2的一次迭代使您很容易用暴力猜测密码是什么。如果每次猜测都花费一秒钟的CPU时间,那么强行强制就变得不切实际。
–mcfedr
2014年6月3日14:11
GPU不能帮助Web服务器快速哈希一个或几个密码。它仅有助于同时散列许多(数千个)密码。
–亚历山大·杜宾斯基(Aleksandr Dubinsky)
15年9月24日在19:18
当bcrypt在本地更难以暴力破解时,NIST怎么会认为PBKDF2很好?这是否意味着,如果您拥有使用bcrypt进行加密的服务,那么将不允许美国企业使用该服务?
– FooBar
17年9月28日在7:56
美国国家安全局(NSA)可能会向NIST施加压力以引入后门程序(例如,wired.com / 2013/09 / nsa-backdoor)。警惕NIST的建议,并始终与独立学者进行仔细检查。
–乔治·帕切德(Georg Patscheider)
19年6月3日14:51
#5 楼
值得一提的是赢得密码哈希竞赛的Argon2。评论
欢迎参加信息安全堆栈交换。由于此答案不能直接解决bcrypt,因此最好将其留为注释。感谢您抽出宝贵的时间回答问题,希望您在这里能获得积极而有益的经验!
–乔纳森
16年1月6日在23:05
我看了看这个比赛,候选人名单不包括bcrypt,scrypt和PBKDF2。
– Amir Fo
19年5月18日在10:47
@AmirForsati-它包括bcrypt(河豚)和scypt(yescrypt)的派生词。可能/可能也来自PBKDF2,但是我没有仔细研究其中的大部分内容。
–ArtOfWarfare
19年10月3日,19:30
评论
关于这个主题,这是一个有趣的阅读:tarsnap.com/scrypt/scrypt.pdf另请参阅:stackoverflow.com/questions/1561174/…
是的,bcrypt有许多精明的支持者,尽管您当然想在性能上调整迭代次数,并在考虑DoS攻击时调整其他防御措施。另请参阅如何安全地对密码进行哈希处理? -IT安全和密码哈希添加盐+胡椒粉还是盐够了?
@tkbx也许几年前。实际上,MD5不再被认为是安全的。例如,看看从2008年起今天认为有害的MD5。
我的意思是任何安全专家都会推荐bcrypt。 :P