# Can you find the salt if you have the original password in plaintext and the hashed version?

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?

• Why do you need to find the salt? If you are an attacker, you already get it? Sep 3 '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. Sep 3 '19 at 18:29
• 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. Sep 3 '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 3 '19 at 18:57
• @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. Sep 3 '19 at 20:30

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.

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.