-1

This question already has an answer here:

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

marked as duplicate by Sjoerd, Steffen Ullrich, forest, Tobi Nary, DKNUCKLES Feb 9 '18 at 2:49

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    If you are worried about hardware attacks you may consider using scrypt, which is harder to optimize in hardware than bcrypt. – Sjoerd Feb 6 '18 at 9:44
  • I read that scrypt is less secure than bcrypt – Alex Robertson Feb 6 '18 at 11:07
  • 2
    For 64 bytes of random data bcrypt isn't even necessary, just use a fast cryptographic hash like SHA256. – AndrolGenhald Feb 6 '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 6 '18 at 15:51
0

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 7 '18 at 2:27
  • Added more notes on the physics limits – David Feb 7 '18 at 2:44
  • if I use bcrypt, what you can suggest to use as an $cost param? – Alex Robertson Feb 7 '18 at 8:34
  • @erickson I read your answer in stackoverflow.com/questions/1561174/… What could you suggest in this case? – Alex Robertson Feb 7 '18 at 8:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.