bcrypt迭代/成本参数的安全性 [英] Security of bcrypt iterations/cost parameter

问题描述

事实A.基于Pigeonhole原理，即使没有发现任何散列函数，每一个散列函数都有无数个冲突。

事实B.重新散列散列，像散列（哈希（密码））没有比散列（密码）更安全，实际上散列（散列（密码））打开一个冲突攻击，这是哈希（密码）不可能的。

事实C.基于B，通过增加迭代，我们达到了大多数密码和盐会返回相同的恒定散列值的程度。我的意思是碰撞的概率很高，甚至100％。

事实上，根据我们的硬件规格，事实上，我们可以增加迭代/成本参数。

因此，通过结合这些事实，我们可以说，在更高的bcrypt成本值下，我们通过增加碰撞概率来降低安全性？
如果答案是否，为什么？

解决方案

BCrypt不会做愚蠢的迭代，它包含原始密码和每一次迭代中的盐。 PBKDF2也是如此，它在每次迭代中都使用HMAC。查看BCrypt的伪代码。

关于信息安全性，有关于效果的说明性答案与迭代哈希碰撞。在实践中，就我所知，即使迭代，碰撞对于密码哈希来说也不是问题。

Fact A. Based on Pigeonhole Principle, every hash functions has infinite number of collisions, even if none is found yet.

Fact B. Re-hashing a hash, like hash(hash(password)) is not more secure than hash(password), actually hash(hash(password)) open up a collision attack that is not possible with hash(password).

Fact C. Based on B, by increasing iterations, we reach a point that most passwords and salts will return same constant hash value. I mean probability of colliding will be high, even 100%.

Fact D. bcrypt has a iteration/cost parameter that we can increase over time, based on our hardware specifications.

So, by combining this facts, can we say that with a higher bcrypt cost value, we decrease security by increasing probability of colliding? If answer is "no", why?

解决方案

BCrypt does not do stupid iterations, it includes the original password and the salt in every iteration. The same goes for PBKDF2, which uses a HMAC in every iteration. Have a look at the pseudo code of BCrypt.

There is a very illustrative answer on Information Security about the effects of collisions with iterative hashing. In praxis, as far as i know, collisions are not really a problem for password hashing, even when iterated.

这篇关于bcrypt迭代/成本参数的安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！