Securely Storing Unsalted Passwords: A Deeper Look
I’m assuming here that your goal is (as @owen suggests) to stop the use of common passwords (e.g. password123) used by your userbase. This is generally a ‘bad thing’ for security as you’ll be artifically constraining password choice in a way that is unpredictable to the user.
If you think about the end-user experience of this feature, would you give them a message ‘hey you chose a common password, pick another’? If so, I’d wager that most users will stick a 1 or ! on the end of the password and try again and/or get frustrated and leave (depending on the site), and as you’re not going to disclose the list of commonly used passwords, there’s no way for the user to know which ones are/are not allowed.
A better approach might be to check the passwords against a common list, which you can point them at and if they choose one of those passwords suggest that it’s a bad idea but let them go ahead if they choose to do so.
That said, assuming that your goal here is as above, you wouldn’t need to have the passwords associated with specific user accounts you would just need them in a list, so there’s not too much wrong (in most cases) with just storing them with the same salt and hashed, then checking as you add new users. If an attacker compromises that table, all he has (if he cracks the hashes) is a list of passwords used in the database with no direct way to associate them back to specific users.
One other risk to consider if you do take this approach is that if the system allows users to self-register, an attacker could just iterate over commonly used passwords to see which ones your users have used as the application will reject those…