Does too long a salt reduce the security of a stored password hash?

Question

Suppose we have passwords that are statistically 7-8 characters long. Is appending a 200 character long salt less secure than a 5 character salt, because of the similar hash function inputs?

I was wondering: what if someone tries to guess the salt by brute forcing the salt with for example the password "123456", or another popular password that can be found in the system or even on a known password from the hacker's own account?

There's no point in brute-forcing a salt, because it is (or at least, should be) different for every stored password, and because it's stored with the hashed password anyway, so an attacker who has access to the password hashes will also have access to the salts. — Mike Scott, Nov 25 '14 at 07:59
The salt won’t strengthen a bad password; it’s still a bad password. — Gumbo, Nov 25 '14 at 08:07
Maybe read this answer on what a salt is and how it 'works'. — Monika, Nov 25 '14 at 10:33
@Gumbo There are users with passwords so weak a salt won't help. And there are users with passwords so strong a salt isn't necessary. But there are also users with a password strength somewhere in between where a salt makes the difference between the password getting broken or not. — kasperd, Nov 25 '14 at 22:58

score 49 · Accepted Answer · answered Nov 25 '14 at 08:47

49

As Mike and Gumbo have mentioned in comments, a salt isn't intended to add protection to bad passwords. It's meant to keep the attackers from breaking the whole database at once. The length of the salt isn't meant to add difficulty to breaking the stored passwords. It's meant to ensure that your salt is reasonably unique compared to others on the Internet, and (if you're doing it right) no two of your users will have the same salt.

Imagine you have 20 users who all have "god" as their password. Consider the following scenarios:

Passwords are unsalted
The attacker can use a precomputed table to break one user's password in very short order. On top of that, once he has the first of the 20, he'll also have the other 19 since their hashes would be identical.
Passwords are salted. Salt used is fairly short. Same salt is used for all users.
The attacker might have to look for a bit, but could possibly come across a precomputed table made specifically for your configuration. After that point, see scenario 1.
Passwords are salted. Salt used is reasonably strong. Same salt is used for all users.
Chances are, the attacker won't find a pre-computed table for your system on the Internet. He'll have to make one of his own. This will take a bit of extra time. However, after that's done, we're back to scenario 1 again.
Passwords are salted. Salt used is reasonably strong. Each user has a unique salt.
This is what you should be doing. Not only will the attacker not be able to find a precomputed table for your system, it's not even worth his time to make his own. Any pre-processing he might do would only work against one user. Even if he hits one of the 20 users mentioned earlier, he won't know the other 19 because the hashes will all be different. Each password must thus be individually attacked, and that's going to take awhile if you're also using a strong and slow hashing algorithm like you should be. Chances are, the weak passwords will still end up compromised eventually. It's just going to take the attacker a good bit more time to get through them all, and you won't have chunks of your users getting compromised at once just because they have the same password.

So, use long salts and make them unique per-user. But don't count on that to help individual users much if they're using "god" as their password.

answered Nov 25 '14 at 08:47

Iszi

27,127
18
101
163

2

Scenario 2 is unlikely. The chance to find such a rainbow table is very small. But scenario 2 and 3 have the option to create a rainbow table yourself, given enough resources and if you know the salt. This is why option 4 is so secure - creating rainbow tables for all salts is simply too much work. The strenght of the salt is not really relevant I guess, but better make it not too weak. – SPRBRN Nov 25 '14 at 10:52
@SPRBRN There's plenty of stupid people and bad implementations out there. I wouldn't be surprised at all if there were at least five people using two-bit salts out there. The longer yours is, the better the chance that you're not matching the next guy's. And the better chance that you won't have two users with the same salt. – Iszi Nov 25 '14 at 14:15
3

The asker talks about a 200 character salt. I guess he is asking if 200 is more secure than (something like) 20, or if it's the other way around. He is not talking about 2 bits, or are you talking bytes here? In case of 1 or 2 bytes, I guess rainbow tables will be available. – SPRBRN Nov 25 '14 at 14:39
3

No competent attacker would bother to create a rainbow table for 3), a direct multi-target attack is at least as efficient. A rainbow table is only useful if you want to crack passwords with the same hash at different times. – CodesInChaos Nov 25 '14 at 14:42
Once you get 'god' you might add it to your dictionnary and try it on each account. Unless your user base is huge, is it really more secure ?

Guillaume

Nov 25 '14 at 14:59

@Guillaume This discussion is really more about the security benefit of hashes, not so much about whether it's a good idea to use "god" as a password. Even if it is #1 in the attacker's dictionary though, it's still going to take them longer to match every user who has that password if the salt is unique per-user than it would otherwise. "Longer" being relative, of course, but still a non-zero difference. – Iszi Nov 25 '14 at 15:11

1

@CodesInChaos Fair point. However, the entire purpose of salt is to eliminate the benefit of pre-computing hashes at all. If you're not using per-user unique salts, there's still some amount of benefit. Even if you're not building a full table up-front, you're effectively building one as you go through and break each user's credentials. – Iszi Nov 25 '14 at 15:15

1

@Iszi The point of a salt it to prevent multi-target attacks, so I don't deny the security benefit of unique salts. But precomputation is just one variant of a multi-target attack. IMO people worry too much about rainbow tables compared with live multi-target attacks. – CodesInChaos Nov 25 '14 at 15:18

1

@SPRBRN I was, literally, talking about two bits. Which is why I picked the specific number of five people. (Actually should have said four, for my intents, but my maths brain isn't warmed up yet.) In any case, the statements made regarding length still apply - the longer your salt, the less likely it'll match someone else's and the the less likely you'll have two users with the same. – Iszi Nov 25 '14 at 15:19

@Iszi, yeah I guess, but for lazy programmers two bytes (or characters) may be even more simple to program than two bits! – SPRBRN Nov 25 '14 at 15:22

2

You forgot 0. Passwords are unhashed. - I know it sounds stupid, but it happens! – corsiKa Nov 26 '14 at 00:08

How are these salts stored? If they're stored next to the hashed password, isn't it back to scenario 1? – Qix - MONICA WAS MISTREATED Nov 26 '14 at 20:06

@Qix The salt isn't supposed to be a secret. Even if the attacker knows the salt, he still won't know what other data (i.e.: password) went into the hashing function to generate the given output. – Iszi Nov 26 '14 at 20:12

kasperd · Answer 2 · 2014-12-21T13:09:41.907

A too long salt will not reduce security. A too short salt will reduce security.

As the salt gets longer security will improve. At some point you will cross a boundary, where you start getting diminishing returns on increasing salt length. And eventually you will cross another boundary, where a longer salt does not add any security whatsoever.

However since a longer salt doesn't have any significant cost, there is little reason to stop increasing the length until you reach the second boundary. Even if you were to increase the salt length beyond that, the only drawback is minor extra cost in terms of storage and processing time.

Sadly salts are more often generated with a length below the lower of the two thresholds.

So what are the two thresholds?

The lower threshold is determined by the number of users and the purpose of the salt, which is to be different for every password ever chosen by any user. If we take some conservative estimates, the number of users worldwide is less than 10^10, and each user has passwords for less than 10^2 systems and over their life time changes this password less than 10^3 times. That means in total there will be less than 10^15 passwords. Given this, one might erroneously conclude that 50 bits of entropy in the salt is enough to guarantee that there will never be two salts repeating, but due to the birthday paradox we have to double that number.

So once the salt grows longer than 100 bits, we start seeing diminishing returns in terms of added security. The 100 bits threshold involved a lot of guessing. The next threshold involves much less guessing. More than 100 bits of entropy in the salt still improves the security, just not by much.

Once the salt grows to be longer than the output of the underlying hash function there is however no added security from making it any longer. What the threshold is depends on the hash function, these range from 128 to 512 bits for typical hashes.

Remember that salts are usually generated with 6 bits of entropy per character, so you would need 86 characters of salt to reach the 512 bits of entropy.

So, adding a really really long salt to the password will never "drown out" the password to some degree, making it easier to find a password with the same hash? Is this a property of the hash functions we use? — Jens, Nov 26 '14 at 07:27
@Jens Yes. We usually pick hashing functions that exhibit the avalanche effect, which means that (ideally) changing any single bit in the input (or adding a single extra bit) will cause approximately half of the bits in the output to change. Therefore the password, even if it is just 1 bit long, causes as much change to the output of the hash as changing the entire salt for a new one would, regardless of its length. — Jules, Nov 26 '14 at 09:24
@Jens If that was the case it would be considered a major weakness in the hash function. It is recommended to use a hash function without known weaknesses. The password hashing can be structured such that the risk of the scenario you describe is minimized, even if the hash turned out to be weak. For example one could simply put the salt before the password and compute: h(salt || password) — kasperd, Nov 26 '14 at 09:58
Just use a Salt the length of the hash code, it matches the max entropy of the hash and the password. Longer Salts do no good. Why worry about the storage size of the salt column in your (no)SQL storage? Total salt bytes grows linear with the size of your user base, which, in any realistic working system should be small compared to the amount of data stored for each (all) users. Sizeof(Authentication Data) << Sizeof(All other System Data). — Andrew Philips, Dec 21 '14 at 17:30
@AndrewPhilips That is the conclusion which my answer leads to. — kasperd, Dec 21 '14 at 18:03
@kasperd Fair enough - I shortened your answer a little bit. ;) — Andrew Philips, Dec 21 '14 at 18:49

score 5 · Answer 3 · edited Nov 26 '14 at 19:54

5

The only property of a salt that is important from a security perspective is that it is globally unique. The length may impact how unique the salt can be, but is irrelevant from any other perspective. Assuming that it has a positive or negative effect on anything is to ask the salt to perform a function that it was never intended to serve.

So, a salt should be long enough to reasonably assure uniqueness, and that is all. Assuming your salt has good uniqueness, any longer will not impact security positively or negatively, but will most assuredly waste storage space.

edited Nov 26 '14 at 19:54

TildalWave

10,801
11
47
86

answered Nov 25 '14 at 21:13

Xander

35,796
27
116
144

Globally Unique may not be practical for large populations, but agreed "for all intents" and purposes. If I am wearing a black hat I have some (or many) of the passwords already, and may even have salts. Breaches due to poor passwords or poor password usage will sail through as your own system oks them. Randomizing the user name / email helps. But this has to be done from the user side. Sadly many use the same values or derivatives for life. Ultimately we are heading toward 3rd party authentication so that separation of duties are enforced. If SSL/RSA cannot be trusted where are we ? – mckenzm Nov 26 '14 at 01:26
2

@mxkenzm globally unique will start to be likely if the numbers of potential salts are greater than the square of the number of passwords. For the forseeable future 128 bits should be plenty for this purpose. – Taemyr Nov 26 '14 at 16:24
A monotonically increasing sequence is guaranteed to be globally unique (1, 2, 3, ...). I don't think this is the "only property" that's important. Use a randomly generated Salt the same length as the password hash and you're highly likely to not only have a system-wide unique salt, but a world wide unique salt. – Andrew Philips Dec 21 '14 at 17:24

Relaxed · Answer 4 · 2014-11-26T12:37:52.410

Others have commented on the proper use of salts and passwords but maybe it's useful to add a word on hash functions because your question seem to suggest a somewhat incorrect intuition of the way they work.

By design, a good cryptographic hash function should not let you guess how similar the inputs were based on the hashed values themselves. Otherwise, it could be inverted by gradually reducing this distance which would be much less costly than pure brute-force guessing. So hash(salt1 + “12345”) should not be more similar to hash(salt1 + “67890”) or to hash (“12345”) than to hash(salt2 + “67890”).

The whole point of the salt is making sure that the inputs (and hence the hash) are not identical even if two accounts happen to use the same password but similarity should not be an issue.

score 0 · Answer 5 · answered Nov 27 '14 at 03:59

0

The length of a salt follows the law of diminishing returns.

At no point does a salt become less secure by being longer,
but it does stop getting meaningfully more secure relatively quickly.

You never "crack" a salt - what you are cracking is the hashed password, to which the salt is appended. The salt just addresses the threat of rainbow tables - the ability to find pre-computed tables of hashes allowing you to skip the laborious process of brute-forcing.

For this purpose, all you need are salts long enough that nobody will already have created comprehensive rainbow tables for all such possible salts yet. And due to the cost of creating a rainbow table and the exponential growth in the number of salts you'd have to calculate as you increase the maximum salt length, this is not a very difficult requirement: only a few characters of salt will already be highly likely to ensure that nobody has calculated comprehensive rainbow tables on salts of your format.

To pick a random value out of nowhere, salts of, say, 16 hex characters or more are going to be quite good, assuming your method for picking them randomly has no exploitable flaws.

Beyond this, the increase in security becomes more and more negligible.

answered Nov 27 '14 at 03:59

thomasrutter

1,637
12
17

Why stop at 16 hex? That's only 64 bits of entropy for the salt and low enough to encounter some salt repeats, however, unlikely. Just set Salt Length to the same length as the hash output. Longer salts have no more entropy, by definition, shorter salts have less entropy, less effective. Finally, storage cannot be an issue. Whatever the s/w is doing, it requires more storage than some simple old user authentication bits. – Andrew Philips Dec 21 '14 at 16:59
I can see the argument for using at least the same amount of entropy in the salt as the hash. But avoiding salt collisions isn't the goal. My point was that due to the relative cost (CPU and storage) of generating separate rainbow tables for many salts, it quickly becomes pointless, and 64 bits entropy is long after that point. It's plausible that someone could pre-calculate and store 65,536 rainbow tables (one per salt) (16 bit salts). Very unlikely someone could generate and store 4,294,967,296 rainbow tables (32 bit salts). And 64 bit salts goes a very long way past that. – thomasrutter Dec 22 '14 at 00:49
Because the cost of using the max salt length is also minimal compared to any potential future (unforeseen) problem or flaw. Why find out later you wish you had selected a choice that is the best you could have done, but didn't and compromised your system's (and users') security in some way. Selecting 64 bits may be practically the same as 128 or 160 or 256 based upon current knowledge, granted; however, algorithms always get easier to break, not harder. If the cost of storage/use is minimal, maxing salt entropy provides a level of insurance. – Andrew Philips Dec 23 '14 at 08:36

Does too long a salt reduce the security of a stored password hash?

5 Answers5

Linked