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:
PASSWORD: Yellow Submarine
- 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.