I read many answers on the stackexchange about Bcrypt, Salt and Where exactly to place the salt. For hashes such as BCrypt it is trivial to extract salt from the hash. So, It doesn't matter really where you place the hash. But, I am assuming here that a hash is generated such as
hash(plain+salt) or something as such.
Most people recommend that, the best way to put salt is in a different column or alongside with the password hash itself. As far as I understand, this also improves performance for credentials validation easily. And also I assume the server side ensures different salts are used to hash different passwords. So, in case of database is leaked, Attacker will have to compute Rainbow tables for all the hash+salt which is tedious.
But, I am considering an edge case here. Let's assume the attacker is specifically interested in cracking password for one particular user. Attacker dumps the database, gets access for the Hash, and Salt as both are either placed alongside each other or in different columns. Now, attacker will be able to build a custom rainbow table for that salt to run attacks.
So, assuming if you are going to do a trade-off between timing to check password & security, Isn't storing salt alongside with password a bad idea?
Wouldn't you prefer using a secondary, isolated database just for storing the salt with respect to id field to pin point which id the salt is applicable to in the
users table in main database?
Would not that be a better option rather than the option which I see daily on Internet everywhere? Or are there any other better options than this ? I do not mind trade-offs between timing/performance of the webpage & security.