You can't. It undoes the security of having a unique salt entirely. The point of having a unique salt is that it prevents use of a rainbow table to identify the password. Storing with a global salt allows that table to be attacked with a rainbow table and most likely identify the original password in many cases.

The alternative to this is to generate a list of salts to try a new password against (the ones associated with previous spammers). It makes a new user creation a slightly more difficult operation since you have to run the password hash multiple times, however it is the only secure way to do what you are talking about. New user creation should also be the only time you need to do this step, so it shouldn't be too, too big of a hit. I'd also only recommend doing it when other indicators seem to support it being a spam user if you want to further reduce the impact.

You could also store bad passwords after they are identified to keep the list short. For example, previous user with salt 1234 had a hash abcd. When a new user submits password "ImSpam" and you try it against salt 1234, you see that it is abcd and now know the actual password for that salt, so you can stop checking against it and only disallow the password entirely. This should keep the list relatively short. You could also have old spam users age out potentially since if you haven't been attacked by that spammer in a while, chances are decent that they gave up.

You can't. It undoes the security of having a unique salt (or any salt for that matter) entirely. The point of having a unique salt is that it prevents use of a rainbow table to identify the password. Storing with a global salt allows that table to be attacked with a rainbow table and most likely identify the original password in many cases.

The alternative to this is to generate a list of salts to try a new password against (the ones associated with previous spammers). It makes a new user creation a slightly more difficult operation since you have to run the password hash multiple times, however it is the only secure way to do what you are talking about. New user creation should also be the only time you need to do this step, so it shouldn't be too, too big of a hit. I'd also only recommend doing it when other indicators seem to support it being a spam user if you want to further reduce the impact.

You could also store bad passwords after they are identified to keep the list short. For example, previous user with salt 1234 had a hash abcd. When a new user submits password "ImSpam" and you try it against salt 1234, you see that it is abcd and now know the actual password for that salt, so you can stop checking against it and only disallow the password entirely. This should keep the list relatively short. You could also have old spam users age out potentially since if you haven't been attacked by that spammer in a while, chances are decent that they gave up.