I'm thinking of hashing user passwords with two different salt strings, one stored in the code which is the same for all users and another stored in the database for which each user has their own unique value.
Would this be more effective than simply storing the values in the database?
Any advice, opinions appreiated.
Thanks
Best practice is to hash with a salt and store both the salt and the hash in the database.
And you want to do it differently why?
The effect is miniscule if anything at all. Consider that a static, hard coded salt can be viewed as nothing more than an alteration to the hashing algorithm - it happens exactly the same way every time, so it may as well be considered part of the algorithm.
But the purpose of the salt is to create some randomness that is similar to extending the (minimum) strength of the password, for the purpose of making offline cracking (including rainbow tables) more resource intensive (non-rainbow-table cracking will require more CPU time, and rainbow tables will require all salts for all strings).
The only way that you'd get any value from this is while the static salt is unknown - the equivalent to the algorithm being unknown. If your binary or your source is available to the attacker, then reverse engineering will demonstrate the algorithm and the hard coded salt.
And if this issue goes public, you will probably have to deal with flack from many security enthusiasts who believe that anything not perfect is completely broken, even though your product already does the right thing and the additional step is just useless.
And, of course, you'll have to deal with maintenance issues of having a static salt - backwards compatibility and bug fixes around the hashing code can be a pain.
The very small benefit of static keys (or salts) is simply not worth the cost. Always make keys and salts dynamic.