Indeed, that is a good point, using the proposed hashing scheme each password would still have the same possible alternate passwords whereas appending a salt to the raw password completely changes the alternatives.
The purpose in using a salt is to reduce the number of password values that will match the hash
I'm not sure this is entirely true because regardless of whether a salt is used or not each hash will have an infinite number of alternate password values, isn't this true? But I think I know what you mean - by using a salt it becomes much more difficult to use rainbow tables to find those alternate values so in practice it's like reducing their number.
and so you need to know the actual password in order to recreate the hash including the salt in order to limit the acceptable values to that one password and to disallow any other input that creates the same hash
As I said, I don't think it's possible to disallow any other input using a hash. It's possible to find many other possible passwords for the same hash even when the salt is used, it's just much more difficult, because an attacker would need to produce a separate rainbow table for each salt. I think completely disallowing any other input is possible only using two-way encryption.
All hmac_sha1 does is to create a keyed hash where you need both the key and the original value to be passed separately in order to get a match with the hash. Since the function applies the key to the already hashed value it does nothing to block using any value for the password that matches the hash. It would prevent being able to use a rainbow table to convert the hashes back into values that will work as passwords if the database is compromised and someone manages to steal the content which would make it more secure than not using it.
That's what I was thinking about - to protect users passwords from being discovered when someone steals the database.
Because any value that produces the same hash will still work though it is nowhere near as secure as using a salt though.
But when using a salt there can still be possible alternate values. I don't yet fully understand how that would change anything, I suppose it could make the system more secure against brute force attacks because the alternate passowords would be very difficult to guess.
Best way to handle it would probably be to add a new field to capture the new salted hash and only get rid of the old hash field once you have given everyone enough time to have logged in and generated their new salted hash.
I'm still thinking about the best way to go with it. The problem is there may never come a time when all users have logged in and changed their password hashes to the new salted version. Because HarryR's solution is better than what is now I can change all users hashes to hmac_sha1 algorithm (salting the hash) and on top of that when a user logs in then recreate their hash with proper salt appended to plain password. At least all passwords would be immediately protected against database theft.