0

This question already has an answer here:

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

marked as duplicate by Steffen Ullrich, David, Anders, M'vy, Xiong Chiamiov Jan 30 '18 at 17:26

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.

  • 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?. Protection against brute-force is instead to use a slow enough hash function. See How to securely hash passwords?. – 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
  • 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
  • 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

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.

  • 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 0:58

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