Safety of bcrypt / cost parameter iterations

Fact A. Based on the Pigeonhole principle, each hash function has an infinite number of collisions, even if there are none yet.

Fact B. Re-hashing a hash like hash (hash (password)) is no more secure than hash (password), in fact the hash (hash (password)) opens a collision attack that is not possible with hash (password).

Fact C. Based on B, increasing the iterations, we reach a point where most passwords and salts will return the same constant hash value. I mean the chance of collision will be high, even 100%.

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

So, putting these facts together, can we say that with the higher bcrypt cost we lower the level of safety, increasing the likelihood of collision? If the answer is no, why?

0


source to share


1 answer


BCrypt doesn't do silly iterations, it includes the original password and salt on each iteration. The same goes for PBKDF2, which uses HMAC on every iteration. Have a look at the pseudocode in BCrypt format.



There is a very illustrative answer on information security about the implications of collisions with iterative hashing. In practice, as far as I know, collisions are not a problem for hashing passwords, even when they are repeated.

+2


source







All Articles