Is it ok to use 6 as a cost of bcrypt algortihm for 64 chars string?

Question

What should the ideal $cost be in this case to prevent brute force attack even by ASIC or an FPGA

$cost = '06';
$secret_key = bin2hex(random_bytes(64));
$store_data = crypt($secret_key, '$2a$.$cost.$'.bin2hex(random_bytes(16)).'$')

Scenerio

Company gives user $secret_key which is generated by above code to give access to withdraw some money and this secret key should never be guessed by hacker.

$store_data is the string that we stored in our database.

So if an attacker gets access to the database and learns the $store_data variable he should not be able to obtain $secret_key.

I have used the bcrypt algorithm to hash but I am not sure if $cost = 6 is secure enough in this case.

Note:

I didn't use password_hash because I will convert all code into Java in the future and in Java there is no equivalent of password_hash

If you are worried about hardware attacks you may consider using scrypt, which is harder to optimize in hardware than bcrypt. — Sjoerd, Feb 06 '18 at 09:44
For 64 _bytes_ of random data bcrypt isn't even necessary, just use a fast cryptographic hash like `SHA256`. — AndrolGenhald, Feb 06 '18 at 15:00
what about in the future? I mean I read that it is unlikely someone will find the way to broke `bcrypt` but they can broke `SHA256` @AndrolGenhald — Alex Robertson, Feb 06 '18 at 15:51

David · Accepted Answer · 2018-02-07T02:44:49.217

If you have 64 truly random (i.e., cryptographically random) bytes, you can use any hashing algorithm that provides preimage resistance to securely store it and prevent an attacker from learning the input.

Algorithms like scrypt and bcrypt provide work factors to make it harder to perform dictionary attacks against the hashes. This is because user-selected passwords tend to have much lower entropy then is ideal for their use case.

With 64 bytes of random data, you can use any cryptographic hashing algorithm with 256 bits of output without any concern about brute force attacks, because it is physically impossible to brute force a 256-bit value. Just iterating over all possible 256-bit values takes more energy than the sun can produce in its lifetime.

Enumerating all possible 128 bit keys requires the total energy usage of Spain for 1 year. Calculating the hashes is even more. Going from 128 to 129 bits doubles the energy requirement, 256 bits requires more energy than the sun can produce. This is a minimal limit of energy storage called the Landauer Limit. (See How Confident Can We Be That Nobody Will Crack a 128-bit key and Wikipedia: Brute Force Theoretical Limits)

My advice, then, is to use SHA-256.

I wouldn't say it's _physically_ impossible, even if it is well out of reach for humanity today. — forest, Feb 07 '18 at 02:27
if I use bcrypt, what you can suggest to use as an `$cost` param? — Alex Robertson, Feb 07 '18 at 08:34
@erickson I read your answer in https://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt What could you suggest in this case? — Alex Robertson, Feb 07 '18 at 08:37

Is it ok to use 6 as a cost of bcrypt algortihm for 64 chars string?

1 Answers1