The "quality" or size of a salt doesn't increase security. Salts can be stored alongside the password, they key is that they must each be unique between passwords but even one byte of unique-ness is unique enough.
The ONLY reason salts exist is to break/combat rainbow tables.
Let's go back to basics: - We take a plain text password. - This works fine for authentication but if our database is stolen then the thief can use all of those passwords without delay. - Logic dictates that what we store MUST be 1:1 equivalent with the original password so the thief will eventually be able to get a list of plain text passwords. - Perhaps we can delay the thief from using the passwords in order to give our users more time to change them? - Suddenly appears: One way hashing algorithms. These require computation to generate and therefore are either expensive or time consuming to compute. - So we turn our passwords into a one way hash. - Problem: Most of our passwords are 5-8 characters long and made up of a small number of characters (A-Z,a-z,0-9). - So now people start generating lists of generated one-way hashes. These lists or "rainbow tables" turn a previously expensive and slow operating into an instantaneous lookup. - How do we combat these lookup tables? - 1: Make our passwords longer - 2: Add unique information for our domain (site salting) - 3: Add unique information per each password (user salting) - 4: Do 1, 2, and 3. - So let's say our users look like this: USERNAME: BobSmith PASSWORD: Yellow Submarine UID: 10302 - We can store their password like this: Hash(USERNAME + UID + PASSWORD) - This accomplishes all three of our anti-lookup requirements above (length, site salt, and user salt). Which means calculating our hashes continues to be computationally expensive. - But keep in mind even with the salt passwords will still eventually get turned back into plain text.