I have a question about password hashing. This is not a question about the the BEST POSSIBLE method of hashing passwords, but rather a more utilitarian question about what is sufficient to hash a password without standard rainbow tables being an issue.
Let me outline a hypothetical scenario. You have an application that is designed without unique salts, and for whatever design reasons, it would be a huge modification to change the application to work with a unique salt for each individual user. So instead of rewriting a huge part of the application, we are looking for a way to hash passwords that is more secure than a pure SHA1 (or whatever standard hashing algorithm), but doesn't involve unique salts.
I'll give two examples of solutions that don't involve unique salts. They each have the obvious advantage of rendering a rainbow table for a pure SHA1 (or any other standard hashing algorithm) useless. Each does, however, have the disadvantage of being able to create a rainbow table for that particular strategy. But if you think about it, using a unique salt has the same vulnerability, if you were to target a single user.
The simplest idea is to have a single salt for all passwords hard-coded. The second is to come up with a more complicated algorithm, such as splitting a password in two by a defined set of rules, hashing each, then hashing the concatenation of the two partial hashes and store that. This can be extended to any algorithm you like.
Is this method sufficient for most applications? Neither is obviously as secure as a unique salt for each user, but if you were targeting a specific user it seems neither more nor less secure if you know the salt for that particular user.
Is that correct? And is it a viable solution for some (or maybe most) cases?