2

Considering:

  • A VERY motivated attacker,
  • A large entropy password, as in 256bits¹ hashed in bcrypt (with recommended cost factor of 12), and
  • Attacker knowledge of everything he might need (except the password): hash, salt, cost, etc [AFAIK those are included in the bcrypt hash]

Is it safe to assume that an exposed bcrypt hash is secure and therefore the attacker won't be able to access the password (or find a collision) any time soon? If the answers is "depends" you are free to make assumptions, please explain why though :)

I did previous research on the topic, and it seems that the answer is YES, but I didn't actually found that in a clear statement. There is a similar question to mine here but IT'S NOT A DUPLICATE, as the answers address implementation/designs flaws and not the security of the hashes. I also found this and it made me question the security of the hashes when he mentions he "side-step the brute-forcing process", although it isn't clear if it's even related to the hash.

Some notes:

1: Just to be sure, I'm calculating entropy as log2(R^L) where R = 62 (Alphanumeric with uppercase) and L = 43 (as in number of characters).

2: I haven't been pwned or anything, I just want to get a clear understanding if it's safe to assume this or if there is something I might be missing.

Justcurious
  • 175
  • 1
  • 6

1 Answers1

2

We don't need a motivated attacker since security is already considered with the strongest attackers. Therefore we can say that they have all information, except the password and have a huge computing power like the Bitcoin miners that can reach ~293 SHA256 hashes per year with massive parallelization.

Now, assuming that your password has strength 256-bit then even we omit the iteration count of bcrypt and set the one bcrypt password test equal to one call of SHA256 then the attackers need around ~2163 years to search. No way! Now consider the iteration count then this number will be higher.

Now, bcrypt is very old dated to 1999. It is not a memory-hard password hashing, that is requiring some adjustable huge memory that prevents parallelization like in ASICs that BitCoin miners use. You should rather use modern password encryption function like Argon2. It is memory-hard, it can be adjusted to require threads. Also, it can have resistance to side-channel attacks that the side-channle attackers can steal the password over time. The side-channel protected version of Argon2 is Argon2i. And, It is always better to use Argon2id if you unsure about using Argon2d (data-dependent) or Argon2i (data-independent).

Side note: collisions are not related to passwords, finding pre-images are related. In finding collision the attacker just needs to find two input values a and b such that h(a) = h(b). In password finding, the attacker needs to find x given the password hash h that satisfies h(x|salt) = . The cost of collision finding is the square root of pre-images attacks due to the birthday paradox.

kelalaka
  • 5,474
  • 4
  • 24
  • 47
  • Thanks or the answer kelalaka, I mentioned bcrypt because I'm not encryption savvy and it is the recommended choice in [OWASP cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id) while Argon2 seems to require some tuning. On the other hand, your side note got me a little confused. So it's not viable to crack the hash, but looking for a collision would be a feasible attack vector? **And therefore the exposed hash is in danger?** – Justcurious Mar 14 '21 at 21:37
  • 1
    scrypt is still better than bcrypt. This is not encryption, this is password hashing, don't confuse the terms. No, exposed hashes are not dangerous, however, one must be sure that all of the users have strong passwords. Like having all 1s is a long password but not strong. Get use of Argon, it is the next generation. --> – kelalaka Mar 14 '21 at 21:54
  • 1
    As long as your password is strong enough and side-channels are not available, searching the password is not possible ( that is the pre-image search). Yes, collisions are not related to crack password hashing, there is no danger there. Consider that the attacker finds two inputs that have the same hash value. 1) does this hash value in the password hash list? 2) collision finding cannot control the salt, unless the hash password function is extremely insecure that we did not see. 3) collision cost 2^128 for a hash function with 256-bit output – kelalaka Mar 14 '21 at 21:59