0

I had done a lot of research about this topic.

Before Researchs

I found that some people suggest that to hide salt is not important: https://crackstation.net/hashing-security.htm

But also this article suggests to use keyed hash which you have to hide some kind of key.

From different sources I learned that the best way to hash is using bcrypt.

Describing Situation

secret string is random string that created by following code: bin2hex(openssl_random_pseudo_bytes(64));

User enter the website, we gave him string which contains both secret string and the salt. And we store hashed version of secret string by using the salt but not storing salt.

Next time, user enter the website and copy&paste secret string along with salt and we verify it by hash function using those.

Question

I am able to hide salt via giving it to the user to store it along with secret string. In this case will hacker be able to use brute force attack? What will be advantage of hiding salt?

it is not a password, so user shouldn't remember it, we just need to find a way to prevent attacker to get the original string that website gave to the user

schroeder
  • 125,553
  • 55
  • 289
  • 326
John Robertson
  • 11
  • 1
  • 6
    It looks like you need to understand the purpose of the salt first. Then you'll see that a salt was not intended as a protection against brute-force attacks. Possible duplicate of [Why is using salt more secure?](https://security.stackexchange.com/questions/14025/why-is-using-salt-more-secure). Protection against brute-force is instead to use a slow enough hash function. See [How to securely hash passwords?](https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846). – Steffen Ullrich Jan 28 '18 at 15:20
  • @SteffenUllrich what about keyed hash? will it protect against it? – John Robertson Jan 28 '18 at 15:27
  • I mean keyed hashes are using secret key which I should hide. If I use salt as the secret key, what willl be difference @SteffenUllrich? – John Robertson Jan 28 '18 at 15:29
  • If the password is 64 random bytes, then you are already protected against brute force, since it is something like number of atoms in the universe times number of atoms in universe, and you don't need to store salt for such keys, as they are not brute-forcable at all. You could even reduce it to 16 bytes and that would still not be crackable. – Aria Jan 28 '18 at 15:36
  • @Aria does bcrypt use salt via just prepend it to the actual password? or use it with some kind of algorithm? – John Robertson Jan 28 '18 at 15:40
  • 1
    @JohnRobertson: You generate a random password for the user. Then you generate a random salt. Then you give both to the user and the user needs to present both for authentication. Thus in essence the password is secret+salt. Will salt protect against brute-force? Of course, given that your "salt" simply means a longer password and the longer the password is the harder it is to guess. But this is not the idea of a salt which is usually used when storing user-created passwords - it is just a longer server-created password instead. – Steffen Ullrich Jan 28 '18 at 16:27
  • @SteffenUllrich is it true that if I use 64 random bytes for secret key, I am totally safe against brute force and I don't need to use salt because combination is more than number of atoms in the universe? – John Robertson Jan 28 '18 at 16:30
  • @JohnRobertson: there is no *totally* safe. But with 64 byte random date you are safe for all practical purposes against brute-force attacks. – Steffen Ullrich Jan 28 '18 at 16:31
  • @SteffenUllrich did you mean I don't need to use a salt? How much it will cost for attacker to get one original text? Because if he does maximum amount of money that he can steal will be $1000. – John Robertson Jan 28 '18 at 16:34
  • @SteffenUllrich your last answer was satisfying for me, but I just need to be sure that how much it coulld cost for hacker to get original text by using brute force attack? – John Robertson Jan 28 '18 at 16:40
  • @JohnRobertson: 64 byte random data are 512 bit random data. This means the search space is 2^512 and the average time to find the solution is 2^511, i.e. about 10^153. In other words practically impossible. – Steffen Ullrich Jan 28 '18 at 16:54
  • @SteffenUllrich thanks :), so just to be sure I don't need salt anymore for bcrypt, right? – John Robertson Jan 28 '18 at 17:52
  • @JohnRobertson: with this strength of passwords you don't need to care about the salt. Note that bcrypt still needs a salt (that's how the algorithm works) but you don't need to care about protecting the salt. Also note that the output of bcrypt is just 24 bytes and thus limits the effectiveness of your 64 byte random password - but even 24 byte (i.e. 192 bit) are sufficient. – Steffen Ullrich Jan 28 '18 at 18:03
  • @SteffenUllrich hmm I think it could be accepted as **answer**. And I am storing hashed version in database, so it shouldnt decrease effectiveness right? Also new answer is posted which suggest HSM that I put the link in my question. hacker could use brute force attack against password for HSM, right? so why most people thinks HSM is secure? – John Robertson Jan 28 '18 at 18:28
  • *"And I am storing hashed version in database, so it shouldnt decrease effectiveness right?"* - your input is 64 byte random and your output is 24 bytes. There is no way to magically pack 64 byte random into 24 byte so of course several bits of strength are lost. – Steffen Ullrich Jan 28 '18 at 18:32
  • Attacker have to get 64 byte string to win. If he get access into our database he will end up with 24 byte hashes which is not worth anything so again to find original string he should try maximum 64^64 combination in brute force attack, is not it? should not he? – John Robertson Jan 28 '18 at 18:46
  • @SteffenUllrich strength of brute force depends on original text right? – John Robertson Jan 28 '18 at 19:24
  • @JohnRobertson: strength on brute-force against a hash depends on finding an input which matches the output (pre-image attack). This does not need to be the original input. – Steffen Ullrich Jan 28 '18 at 19:28
  • so if user store 64 byte random string and my database store 24 byte hash value, strength on brute-force will be depend on 64 byte random string not 24 byte hash right? – John Robertson Jan 28 '18 at 19:38
  • 1
    Why cannot you use bcrypt as it is intended to be used ? Why cannot you store the salt ? And why do you need such a huge secret ? – A. Hersean Jan 30 '18 at 13:23

1 Answers1

1

The canonical way to secure an additional secret key is with an HSM, as in this answer.

When properly implemented, an attack cannot be carried out without access to the HSM itself. So an attacker cannot steal a list of hashes and crack them somewhere else.

Royce Williams
  • 9,318
  • 1
  • 32
  • 55
  • But hacker could use brute force attack against password for HSM, is not it? – John Robertson Jan 28 '18 at 17:51
  • 1
    They would have to perform the attack on the same hardware system as the one that the HSM is plugged into. They could not steal the hashes and crack them somewhere else. That is the purpose of the HSM . – Royce Williams Jan 28 '18 at 18:30
  • 1
    @JohnRobertson HSMs are not (easily) vulnerable to brute force attacks because of built-in rate limiting. Even if an attacker has access to the HSM (e.g. via a compromised server-side application) they can't verify a million password candidates because a (properly configured) HSM will refuse to do so. – Peteris Jan 29 '18 at 00:58