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.