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.


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

  • 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?. Commented Jan 28, 2018 at 15:20
  • @SteffenUllrich what about keyed hash? will it protect against it? Commented Jan 28, 2018 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? Commented Jan 28, 2018 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. Commented Jan 28, 2018 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
    Commented Jan 30, 2018 at 13:23

1 Answer 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? Commented Jan 28, 2018 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 . Commented Jan 28, 2018 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
    Commented Jan 29, 2018 at 0:58

Not the answer you're looking for? Browse other questions tagged .