I have been reading on correct procedures for storing and checking user passwords, and am puzzling a little with salts.
I get the idea that they are to prevent use of such tools as rainbow tables, but to me the idea of storing the salt along with the hash seems a potential security problem. Too much data in one place for my liking.
The idea I have that I would like to run by folks is to use a 'lucky number' to create a salt from a portion of the password hash. Basically, along with choosing a password, a user would choose a 'lucky number' as well. This number would then be used as the starting index to retrieve a salt from the hashed pass.
So a very basic example would be something like this.
Pass = "Password"
Lucky Number = "4"
Pass Hash = "00003gebdksjh2h4"
Salt Length = "5"
Resulting Salt = "3gebd"
My thinking is that as the 'lucky number' would not need to be stored, the salt would then also take computational time to work out and so make any attacks even more difficult. Plus means storing slightly less data.
It wouldn't add more security. The goal of using rainbow table is to have a map of combinations of dictionary words and relevant hashes. By using a more-or-less distinct salt (which in general shouldn't be found in a dictionary) for each password hash you compute, you force the attacker to generate a new set of rainbow tables for each entry, which would be prohibitively computationally expensive. At no point (except for generating the hash table) the attacker calculates hashes, so your strategy fails here.
On the other hand when using a regular dictionary attack the attacker only needs a constant-time computation to calculate the salt, which he would have to compute only once for many millions or more combinations of hashes he would have to generate. It would only work if it was more computationally expensive than generating all that, but then you'd have to make the same computation each time a user wants to log in, which is not feasible.