What is the optimal length for user password salt?

Question

Any salt at all will obviously help when salting and hashing a user's password. Are there any best practices for how long the salt should be? I'll be storing the salt in my user table, so I would like the best tradeoff between storage size and security. Is a random 10 character salt enough? Or do I need something longer?

Answer 1

Edit: My below answer answers the question as asked, but the "real" answer is: just use bcrypt, scrypt, or Argon2. If you're asking questions like this, you're almost certainly using tools at too low a level.

Honestly, there's no defensible reason not to have the salt be the same exact length as the hashed password. If you're using SHA-256, then you have a 256-bit hash. There's no reason not to use a 256-bit salt.

More than 256 bits won't net you any improvement in security, mathematically. But going with a shorter salt may always end up with a situation where a rainbow table catches up to your salt length -- especially with shorter salts.

Answer 2

Currently accepted standards for hashing passwords create a new 16 character long salt for every password and store the salt with the password hash.

Of course proper cryptographic care to create really random salt should be taken.

Answer 3

Wikipedia:

The SHA2-crypt and bcrypt methods—used in Linux, BSD Unixes, and Solaris—have salts of 128 bits. These larger salt values make precomputation attacks for almost any length of password infeasible against these systems for the foreseeable future.

128-bit (16-byte) salt will be enough. You can represent it as a sequence of 128 / 4 = 32 hexadecimal digits.

Answer 4

One answer might be to use as size of salt the value that the hash you are going to use provides in term of security.

E.g. If you are going to use SHA-512 use 256 bit salt since the security provided by SHA-512 is 256 bit.

Answer 5

Most of these answers are a bit misguided and demonstrate a confusion between salts and cryptographic keys. The purpose of including salts is to modify the function used to hash each user's password so that each stored password hash will have to be attacked individually. The only security requirement is that they are unique per user, there is no benefit in them being unpredictable or difficult to guess.

Salts only need to be long enough so that each user's salt will be unique. Random 64-bit salts are very unlikely to ever repeat even with a billion registered users, so this should be fine. A singly repeated salt is a relatively minor security concern, it allows an attacker to search two accounts at once but in the aggregate won't speed up the search much on the whole database. Even 32-bit salts are acceptable for most purposes, it will in the worst case speed an attacker's search by about 58%. The cost of increasing salts beyond 64 bits isn't high but there is no security reason to do so.

There is some benefit to also using a site-wide salt on top of the per-user salt, this will prevent possible collisions with password hashes stored at other sites, and prevent the use of general-purpose rainbow tables, although even 32 bits of salt is enough to make rainbow tables an impractical attack.

Even simpler-and developers always overlook this-if you have unique user IDs or login names, those serve perfectly fine as a salt. If you do this, you should add a site-wide salt to ensure you don't overlap with users of another system who had the same bright idea.