6

Possible Duplicate:
Password Hashing add salt + pepper or is salt enough?

In the official documentation of the PKCS5 V2.0 standard, we can read "The salt can be viewed as an index into a large set of keys derived from the password, and need not be kept secret."

The part "need not be kept secret" is interesting.

Since the salt is used to add a huge range of password possibilities (or to create two different keys if two users had the same password), what is the purpose of letting the salt insecure?

I understand that typically, an attacker wont have access to the salt, so it will complicates his job to find the right password. But if an attacker knows the salt, where is the "magic"? Knowing the salt is like perform a traditional dictionary attack (if we exclude the iteration count)!

Is there something that I dont understand? I know that knowing the salt dont break the security but, saying that it "need not be kept secret" sounds strange to me.

Community
  • 1
Normand Bedard
  • 241
  • 1
  • 3
  • 3
    This question is covered well by [Password Hashing add salt + pepper or is salt enough? - IT Security](http://security.stackexchange.com/questions/3272/password-hashing-add-salt-pepper-or-is-salt-enough) and [How to securely hash passwords? - IT Security](http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords) so I suggest marking it as a duplicate and referring folks to the former. In summary: the salt prevents precomputed space/time tradeoffs, and it *may* be useful to add a "pepper" (a secret salt) – nealmcb May 30 '11 at 14:40
  • @nealmcb: I guess that, as a separate community, we're free to adjust the rules a bit for this site. On Stack Overflow it has been so that duplicates -- within reason -- are permitted, because there can be synonym words or multiple perspectives on the same question. Thus having the same base question answered multiple times can make the answers more 'discoverable' for someone who thinks in different terms. –  May 30 '11 at 18:15
  • 1
    @jesper I'm certainly not asking for the question to be deleted. The nice thing about SE, though, is that a duplicate is still visible as a question, and has a prominent link to the original question. So it attracts searchers and yet gets them to a well-vetted answer. I think the bigger problem, especially for a security site, is having multiple places with answers, since it is all too common that a misleading answer gets a lot of attention without being corrected. And if we want to attract real experts, we don't want them to have to answer the same question over and over. – nealmcb May 30 '11 at 18:33
  • @nealmcb: Valid points all. I can't say what will work best for this community. :-) –  May 30 '11 at 19:03

2 Answers2

4

Keeping something private is difficult (i.e. expensive). For a confidential data element, usually called a "key" (sometimes a "password" when the said key can be stored in a human-based system), we must think about the whole key life cycle: how, when and where it is created, stored, copied, and erased. In some (many !) contexts, proper key management requires physical tamper-resistant storage systems (smartcards, HSM...); these do not grow on trees. There is no need for any reason for wanting not to keep something private; rather, we need explicit reasons for making something worth being private.

A salt is not a key (otherwise we would call it a key, not a salt). Its point is to be distinct for every instance, even if the same key is used. The salt prevents many types of cost sharing, where an attacker can attack N protected elements (e.g. hashed passwords) for less than N times the cost of attacking one. One form of cost sharing is precomputed tables, e.g. "rainbow tables". A salt defeats that by being unique for each instance.

By allowing the salt to be public, we make it much easier to have a unique salt per instance. Managing so many secret keys would be very hard, but for public elements, we just invoke a PRNG and store the value as it goes, without further ado.

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
0

"need not be kept secret"

They probably mean something like "doesn't have to be encrypted with strong cryptography"; but not "should be actively publicized to everyone".

The main purpose of the salt is to avoid cost sharing. Cost sharing would be to pre-computing a hash table once, and then use that hash table to attack all user accounts at once. (Or worse still, effectively attack user accounts on many systems.)

A large and random salt effectively protects against cost sharing. And it does so even if it's stored in plaintext next to the hashed representation of the password.

Think of it like this: Performing a search through a gigantic dataset takes time; RAM sizes and RAM I/O speeds are limited. At some point the size of the pre-computed hash table becomes prohibitive. The salt has then served its purpose, whether it is kept secret or not.

(When the hash table approach isn't feasible, the attacker would presumably switch to just running the hash function. Fx brute-force attacking by hashing the potential passwords in parallel across a cluster of cheap machines.)

Community
  • 1