1

Suppose that I have a password in plaintext. I also have the hashed version of the password. Say it uses MD5. Is it possible to find out what the salt is given the above information? I'm guessing not?

user71643
  • 11
  • 1
  • 2
  • 1
    Why do you need to find the salt? If you are an attacker, you already get it? – kelalaka Sep 03 '19 at 18:26
  • It was just out of curiosity. However, perhaps the same salt is used somewhere else, so knowing what it is might be useful information for an attacker. – user71643 Sep 03 '19 at 18:29
  • 1
    Salt is random and can be around 128-bit. finding a collision with birthday paradox you need $2^{64}$-salt. To build a rainbow table for each salt; don't try to calculate the cpu, storage resource and time and money. – kelalaka Sep 03 '19 at 18:32
  • MD5 is a cryptographic hash and does not have a salt as input. You probably mean HMAC with MD5 or PBKDF2 with MD5. Anyway, MD5 is broken for collisions resistance, but that doesn't help you find the salt. Don't use MD5, though. – tylo Sep 03 '19 at 18:57
  • @user71643: Salt is always known in advance. – mentallurg Sep 03 '19 at 20:16
  • 1
    @user71643: You should expect that the attacker sooner or later obtains the binaries of the hashing algorithm you use and obtains also hashes, because hashes have to be stored somewhere - in a database, in the hashing application etc. – mentallurg Sep 03 '19 at 20:30
  • OJW's answer short and simple : $${}$$Getting salt from hash(salt+password) would be just as difficult as getting password from hash(salt+password). – kelalaka Sep 04 '19 at 17:13

3 Answers3

2

No. It's impossible to find the salt if you don't already have it unless something is seriously broken or unusual.

You may already have the salt because it's common practice to store the hash together with the salt. Many password hashing interfaces even output a hash string which contains the “real” hash, the salt, and additional metadata identifying the algorithm and the iteration count. For example, the output of the Unix crypt() function looks like $5$salt$hash where 5 identifies the hash algorithm, salt is the salt encoded in Base64 and hash is the output of the underlying function also in Base64. The PHC string format, promoted by the Password Hashing Competition, has a very similar format.

But if all you have is the hash itself, then for anything remotely resembling a proper password hash and even for most things that aren't, the only way to find the salt is by trying every possibly salt until you find the right one, just like the only way to find the password is by trying every possible password until you find the right one. Even something broken like MD5(password + salt) (broken as a password hash because it's far too fast) makes it impossible to find the salt without guessing it. That's preimage resistance, and even hashes like MD4 and MD5 that are badly broken with respect to collision resistance still have preimage resistance.

With the password, guessing is a real risk: most users choose passwords that are at best a slightly modified dictionary word, which can be guessed in seconds of computer time with a broken hash like MD5 and may still be barely manageable but slow with a properly slow hash. But the salt is not chosen by a human. It's usually generated randomly so brute force among all possibilities is the only way. And it's usually long enough that brute force is not feasible. You'll only realistically be able to find the salt if either it wasn't generated randomly (or with a non-cryptographic random generator, or with a badly seeded generator), or if it's too short for comfort.

Gilles 'SO- stop being evil'
  • 19,134
  • 4
  • 50
  • 92
2

If the hash function is preimage resistant, then it's hard to find any input that hashes to a randomly selected given result. In this case it's not a randomly selected result because we know part of the input, but that doesn't make guessing the salt any easier.

Disclaimer #1: MD5 shouldn't be used anymore because its collision resistance has been utterly broken, but its preimage resistance hasn't been broken in practice so far.

Disclaimer #2: People should only ever be hashing passwords with specialized password hashing functions like Argon2, bcrypt or PBDKF2. Concatenating a salt and password yourself and passing it to any plain old hash function is a bad idea.

Luis Casillas
  • 14,468
  • 2
  • 31
  • 53
0

This question has already been answered over on Information Security SE.

Short answer: Possible but difficult.

The time and resources it would take would likely not be worth it, since best practice is for a salt to not be intentionally reused.

From Auth0:

The salt doesn't need to be encrypted, for example. Salts are in place to prevent someone from cracking passwords at large and can be stored in cleartext in our database next to the hashes. However, we do not want to make the salts readily accessible to the public.

freginold
  • 119
  • 5
  • "do not want to make the salts readily accessible to the public" - it means security through obscurity, which is not a security. – mentallurg Sep 03 '19 at 20:17
  • 1
    If somebody published some text somewhere, it does not mean it is correct. You are referring a bad post. I vote your answer down. – mentallurg Sep 03 '19 at 20:25
  • Possible but difficult is wrong. I don't see where you read that in the thread you're citing. It's either effectively impossible if the system was configured correctly, or possible and not particularly difficult if there was a misconfiguration. – Gilles 'SO- stop being evil' Sep 03 '19 at 20:32
  • @mentallurg which post is bad, the IS SE answer or the Auth0 blog post? – freginold Sep 03 '19 at 20:32
  • @freginold: Bad is the post that you cited, "do not want to make the salts ... public", from auth0. – mentallurg Sep 03 '19 at 20:35
  • @Gilles see OJW's answer ("Getting salt from hash(salt+password) would be just as difficult as getting password from hash(salt+password).") or Lucas' answer ("So it will largely depend on your salt length and algorithm used how feasible it actually is to brute force a salt if you don't know it.") – freginold Sep 03 '19 at 20:36
  • @freginold: The other post, on SE, is formally correct, but the discussion there is useless. It is like to discuss "is it possible to find out what hashing algorithm was used". The defender of the information should always expect that the only thing that the attacker does not know is password, and that everything else - hashing application or hashing binaries, salts, hashing parameters like number of iterations etc. - this everything is known to the attacker. – mentallurg Sep 03 '19 at 20:39
  • 1
    Oh, I see. You misunderstood. It's difficult as in requiring an unfeasible amount of computing power unless something was misconfigured. So it's practically impossible unless there was a misconfiguration (in Lucas's answer: a bad choice of salt length or algorithm). And if there was a misconfiguration, it isn't difficult. – Gilles 'SO- stop being evil' Sep 03 '19 at 21:04
  • @mentallurg - That's a saying and a rule of thumb not a law. The use of secrets like passwords and keys is a large and valid part of security, that not what is really meant by the phrase "security by obscurity", that's more about relying on secrets being tricky / unlikely to be discovered. – Roger Heathcote Aug 13 '20 at 21:07
  • @RogerHeathcote: You understand "security through obscurity" correctly. But I'm not sure if you read the answer, because you seem not to understand why it is applicable in this case. The answer suggests to hide salt. Then either it means IV, not salt. Or if salt, then it is must be public. But using what is meant to be salt and hiding it is namely an attempt to create a "tricky" algorithm and thus hoping to increase security. Such approaches to security implementation we call "security through obscurity". – mentallurg Aug 14 '20 at 23:49
  • @mentallurg Keeping salts secret is no more security through obscurity (STO) than using a private key to sign your JWTs, or any other server side secrets you use. STO is allowing your secrets to leave your control and relying on them being hard or unlikely to be discovered for security. Not publishing your salts is not STO, it is keeping information secret which is a quite different thing. – Roger Heathcote Aug 16 '20 at 21:43
  • @RogerHeathcote: 1) What you mean by no more? You want to say that a thing that was security through obscurity for 20 - 30 years became suddenly no security through obscurity? No way. Explain us :) 2) Per definition salt is public. Salt is used namely to avoid necessity to use any secrets. If you hide salt and need some secret or some secure method to access salt, it is not salt. Using of improper wording leads to confusing, not to security. – mentallurg Aug 18 '20 at 01:46
  • @mentallurg SO comments is not the place for extended discussion. I think you are wrong but if you want to have it out then start a thread on a more appropriate forum and link me to it. – Roger Heathcote Aug 18 '20 at 06:57
  • @RogerHeathcote: 1) start a thread on a more appropriate forum - Why not on SE? You can create chat room on SE directly, see the chat link in the page footer. 2) I am not trying to convince anyone. We are living in a free society and you are free to believe what you want :) I explained what salt is what is its purpose. If smb. uses word "salt" for other purpose, this leads to misunderstanding. But everyone is free to do anything one wants to. If you create chat and ask me "why" questions about salt, I will answer them. But I will no try to convince you in anything. – mentallurg Aug 18 '20 at 20:47