19

Is it possible to get the salt if I have the hash and original password?

My gut feeling is no, but would it be impossible or will it just take very long?

Jake
  • 477
  • 2
  • 6
  • 12
  • 3
    Yes it would be the same as bruteforcing the password. Like GdD said theres no point to trying to find the salt if you already have the password. Just generate a new salt and a new hash, the salt's only purpose is to be a force multiplier in the fight against bruteforcing, it isn't supposed to have any value beyond that. – Andrew Hoffman Nov 20 '14 at 15:07
  • 12
    just wanted to say: the only reason i can imagine anyone would want to learn the salt is so that they could use the salt to decrypt other passwords in the same database; however, assuming a salting scheme was properly implemented, each hash has an independently generated random salt from each other hash. learning the salt for one password *shouldn't* provide you with the salt for all the passwords (but all too often, it does). – Woodrow Barlow Nov 20 '14 at 19:43
  • 3
    Given that salt and hash are usually concatenated and stored in a single database field, what would be the scenario where you would want to compute the salt from the hash? – kasperd Nov 21 '14 at 04:41
  • @WoodrowBarlow Exactly what I was thinking. Thanks. Especially if I have several original passwords and corresponding hashes. – Jake Nov 21 '14 at 06:31

3 Answers3

44

Getting salt from hash(salt+password) would be just as difficult as getting password from hash(salt+password).

OJW
  • 496
  • 4
  • 4
  • 23
    Probably more difficult since salts are supposed to be random, which usually makes them stronger than the password itself depending on the salt size. – Andrew Hoffman Nov 20 '14 at 15:04
  • 3
    I got used to small enough salts to make the brute force reasonable. BF of a 4 byte password is doable, so BF of a 4 byte salt is also doable. – Joshua Nov 20 '14 at 16:17
  • @Joshua Some systems have indeed used salts that short. But there are some security benefits from using a longer salt, and not much reason to use a short salt. So any modern system would use a salt which is too long to brute force. – kasperd Nov 21 '14 at 04:37
  • 2
    @AndrewHoffman: Salts are not required to be *random*; instead, they should be *nearly unique*. If no good source of randomness is available, a system could concatenate the time that the password was changed with an account identifier and use that as a salt, in which case brute-forcing may be relatively easy if one knows the account in question and the approximate time the password was changed. – supercat Nov 21 '14 at 21:46
  • @supercat yeah sorry, its just the only way i've seen them generated. No need to have a unique constraint on the salt column, nearly unique is good enough, and randomly generated usually satisfies that. – Andrew Hoffman Nov 24 '14 at 14:02
12

I'm not really sure why you would want to find the salt, since generally the salt is not considered secret. Basically in your case the salt is essentially the password as you do not know what it is and the password is your salt (let's take semantics aside that dictates as the password will probably not be globally unique) as it's not secret.

The PBKDF2 standard states that at least 64 bits should be used. However Thomas Pornin states that:

Salts must be unique; that's their one and only job. You should strive, as much as possible, to never reuse a salt value; the occasional reuse is rarely critical but should still be avoided). With reasonably designed password schemes, there is no other useful property in salts besides uniqueness; you can choose them however you want as long as you do not reproduce the exact same sequence of bits. Uniqueness must be understood worldwide.

A common way to have more-or-less unique salt values is to generate them randomly, with a good generator (say, one which is fit for cryptographic usages, like /dev/urandom). If the salt is long enough, risks of collisions (i.e. reusing a salt value) are low. If you use n-bit salts, chances of a collision become non-negligible once you reach about 2n/2 generated values. There are about 7 billions people on this planet, and it seems safe to assume that they, on average, own less than 1000 passwords each, so the worldwide number of hashed passwords must be somewhat lower than 242.7. Therefore, 86 bits of salt ought to be enough. Since we kind of like so-called "security margins", and, moreover, since programmers just love powers of two, let's go to 128 bits. As per the analysis above, that's more than enough to ensure worldwide uniqueness with high enough probability, and there is nothing more we want from a salt than uniqueness.

Note that it will also depend on your password hashing algorithm, there are currently three accepted password hashing algorithms which are considered secure:

  • PBKDF2
  • scrypt
  • bcrypt

These are quite slow algorithms, making it less feasible to brute force the salt. Now if your salt is 64 bits and your algorithm is slow, it's not really feasible at all. Let's say you have a 64 bit salt:

((264) * t)/2

Where t is the amount of time it takes to calculate a single hash and divided by two as statistically you will probably find it after having done half of the hashes. Regardless to say that's A LOT of time.

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.

Community
  • 1
Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
6

Assuming you know the hash function and method used to generate the hash from the password and salt it is possible to discover the salt if you have the original password and the end hash. It would be using brute force - there's no clever or quick way to do it.

In your typical scenario your hash is generated by 1) hashing the password then 2) combining it with the salt, and then 3) hashing the combination of password hash and salt. If you know 1) and 3) and you know the length of the salt you could try every combination of the missing salt until you find it. This would take a great deal of computing power and time.

I cannot think of a scenario where discovering the salt is worthwhile. Salts are supposed to be one-time use only, and you don't have to protect them. There are plenty of scenarios where the salt is sent over unencrypted channels, so chances are you wouldn't need to discover it anyway, if you can get the end hash you probably already have the salt. Even if someone implemented a crypto system that used a static salt (a bad idea!) you wouldn't have to brute-force it as you can probably get it by other means.

GdD
  • 17,291
  • 2
  • 41
  • 63
  • 1
    Wouldn't a salt value found this way be just one, out of a set of possibly more than one valid salt values? – Monika Nov 20 '14 at 14:48
  • The only way you'd get more than one salt is if there was a collision where 2 different inputs into the hash mechanism produce the same end hash. That's pretty unlikely. – GdD Nov 20 '14 at 14:57
  • 6
    @GdD If each of your password and salt is longer than the hashed output, it is pretty likely that 2 different inputs will produce the same output. Or at least that is what my pigeon says. – Yakk Nov 20 '14 at 15:51
  • Perhaps I'm not understanding what you are stating... – GdD Nov 20 '14 at 16:15
  • 5
    It's unlikely you'd be able to find the 2 or more inputs that produce the same hash, but they are guaranteed to exist since you're taking a long input and getting a short output (see Pigeonhole principle to understand Yakk's clever pun) – John Gibb Nov 20 '14 at 16:22