encryptionsalt-cryptographyhash-functionrainbowtable

Salt practices clarification


I was recently reading Application Security For The Android Platform by Jeff Six and I came across a statement that I found puzzling. In the encryption section while describing salts and hashing functions this statement was made

Just like with IVs [Initialization Vector], salt values should be random but they do not need to be kept secret.

Is this true? Because my understanding of salts and hashing functions was that this statement is just wrong and the salt needs to be protected because if the salt is released a new rainbow table can be generated making the salt unnecessary? Is this correct? Or does the salt really not have to be kept secret and why is this?


Solution

  • The salt doesn't have to be kept secret because it will be a 64-bit or 128-bit random number, and the attacker would be unable to use any rainbow table that didn't incorporate that salt. In effect, the attacker would be brute-forcing each individual password (because each password will have its own salt, of course — no two passwords should be hashed with the same salt).

    The rainbow table attack is based on storing precomputed hashes for all possible password inputs (up to a certain length, naturally). It is infeasible to store rainbow tables for every conceivable salt of 128-bit complexity: a rainbow table to cover just single byte passwords that accounts for 128-bit salts would be approximately 280 Terabytes (that's 1027: one thousand trillion trillion 1TB hard drives).