2
$\begingroup$

I was recently thinking about password hashing (maybe caused by the PHC progression).

I started to think a little more about it and got stuck at this question:

What security properties do password-hashing related salts actually need?

I think they need to be globally unique (that's how I usually construct them). This means the same salt should never be used twice - by anyone. This would mean I'd had to choose my salt to be collision resistant resulting in 512-bit length and a CSPRNG for generation.

Is this overkill or are shorter and less defensive solutions also secure?
(this is basically the same question as the bolded)

If you need to make assumptions regarding the schemes, standard schemes (without pepper) should be assumed, like bcrypt, scrypt, Argon2, PBKDF2.

Improve this question
$\endgroup$
1
  • $\begingroup$ I would say that given a particular password/algorithm combination, the bit length of salt input should be greater than the equivalent bit length of security requirement, multiplied by the probability of password collision for all users of the algorithm (which is high, say 1.0), multiplied by the lifetime expected invocations of the algorithm (32 billion?) to create new hashes. Therefore if 128-bit security is desired, use 164-bits of salt.. ?. $\endgroup$
    – Richie Frame
    Commented Aug 31, 2015 at 3:59

2 Answers 2

Reset to default
6
$\begingroup$

512 bits is overkill for even global uniqueness. 256 bits should be enough, with a good random number generator: even if every person on earth generated one every nanosecond, it would take a million million years to reach the birthday bound.

However, I agree that global uniqueness is a good idea. If anyone anywhere uses the same salt and password hash (or other salt-using algorithm), an attacker could theoretically attack those in less time than otherwise.

If you had a unique application-specific pepper (additional salt that is shared by all users), you could safely use salts that are only locally unique, for example outputs from a counter. This might in some cases be useful for saving space.

Improve this answer
$\endgroup$
1
  • $\begingroup$ For the application-specific "pepper" case, would a salt like pepper || user_id || nonce generally suffice? Where pepper is a unique application-wide constant, user_id is a unique per-user constant (never changes either!), and nonce is just a simple random 4-byte integer (stored next to a user's password hash) changed during password resets. Would 4-bytes really be fine for such a nonce? Or would it have to be 64-bits or even greater? (128-bits) $\endgroup$
    – ManRow
    Commented Jul 9, 2023 at 2:37
0
$\begingroup$

Given that nobody has yet demonstrated a SHA-1 collision, 160 bits is likely sufficient to ensure global uniqueness. Especially as the salt is chosen by the defender and not the attacker.

Further, given that the purpose of a salt is only to make dictionary attacks require an infeasible amount of storage, 80 bits is probably all that is necessary.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.