How long should a salt be to make it infeasible to attempt dictionary attacks?

Question

I\'m designing an authentication system that works like the following:

1. User enters password
2. Salt is generated.
3. Password is hashed with whirlpool<

Answer 1

I think you are misunderstanding the concept of a salt. Salts do not prevent or slow down dictionary and brute-force attacks significantly.

The whole point of using salts is to avoid the possibility that someone has already precomputed a dictionary/brute force attack for your password hashes (for example using rainbow tables). Thus, it only needs to be long enough to exclude the possibility that such a table already exists for a specific salt.

Considering the typical size of such a rainbow table, it is extremely unlikely that somebody already has precomputed such tables for salts of even small size like 8 bytes or so (consider the number of possible salts: 256^8 = 18446744073709551616). The premise is of course that the salts are randomly generated and that you don't use the same salt value multiple times. 64 bytes can't hurt, of course, there's nothing wrong with that.

However, if you want to make brute-force or dictionary attacks infeasible, it won't help you to use a longer salt. Instead, make your users to choose strong passwords and consider using key stretching.

Answer 2

My copy of Practical Cryptography (Ferguson, Schneier) with a copyright date of 2003, suggests using 256 bits (32 bytes) for salt length. It says that 128 bits is "probably" okay, but, as it points out, bits are cheap. Given that, the relatively minimal cost of storing 64 bytes for a salt on disk for each password seems reasonable. It is probably overkill but it would not hurt.

You may also want to consider password stretching (repeat the hash function many times) to increase the computational complexity of attacking a password via brute force. Adding a few hundred milliseconds to the cost of checking the password can greatly increase the cost of a brute force attack.

Answer 3

Book:

Cryptography Engineering: Design Principles and Practical Applications

by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno

21.2.1 Salting and Stretching

Since bits are cheap, for simplicity we suggest using a 256-bit salt.

Answer 4

The salt determines how much space is required to store a pre-computed table (such as a Rainbow Table) that allows an attacker to quickly lookup a password for a given hash.

The number of hash iterations (not the salt) is what determines the time required for an attacker try each password in his dictionary of candidates.

Every bit of salt doubles the space required for the lookup table. So, 8 bytes (64 bits) would result in a space multiplier of 16 million terabytes—taking the total space well into the yottabyte range (and probably beyond the reach of most attackers).

Answer 5

A salt is used to add additional random bits to the password to make certain attacks less efficient. So the more entropy the salt adds, the better.

Currently, PKCS #5 recommends a salt length of at least 64 bits entropy, the often recommended bcrypt uses 128 bits and you could even use more. But there certainly is a point where you won’t add additional practical complexity as the resulting complexity is already utopistic.

So you should have at least one unique salt per password so that only one password can be cracked at a time. At best, use a already proven password storage scheme.

Answer 6

8 Bytes are sufficent.

When you look in Linux (kernel version 3.16) in /etc/shadow, where the passwords of the user are saved, you can see a form like this:

$id$salt$encrypted_password

• id defines the hash algorithm

In my Linux-Version the salt is 8 digits so 8 bytes and i think the kernel developers know what they do, so i also use 8 Bytes for my salt, which comes from a Cryptographically Secure Pseudo Random Generator source. In Linux you can simply read /dev/random (which blocks when entropy is low) or /dev/urandom (which doesn't block).

For more information read the manpages for crypt.