I have read through many guides about best practice to create a user reset password token. They're all saying that we should create another database table and store the hashing of the token.
And it comes to my mind that why don't we just re-use the current hash password to sign the reset token? We email the user with that token, then check if they are match.
If the user changes the password, the token would be invalid then so it makes sure one time use. So now we don't have to add extra table.
Not sure if I miss something here?
Well, you wouldn't introduce a major and directly exploitable vulnerability by doing so, but consider a few things to see why I think it wouldn't really be recommended.
The password hash is known to anybody that knows the password. It's probably not the actual user, but what if as an attacker, I don't want to directly try passwords because that's too noisy, gets into logs, provokes alerts and so on. Instead, I make the user change their password somehow (eg. as a man in the middle I intercept all login responses or whatever, it doesn't matter how) and then I guess their password by trying to change it, knowing the only secret that was used for the token. This might corrupt auditability at the very least.
Also crypto algorithms sometimes have weaknesses. Not very likely, but one such weakness might allow finding out bits of the key if enough ciphertexts or hashes (some potentially with plaintexts) are known. You don't want an attacker to ever be able to find out user passwords, especially because those tend to be reused unfortunately.
So basically it's all a bit subtle, maybe only a building block in a complex attack, but you shouldn't use secrets beyond their purpose. If you do so, weaknesses will be linked together, weakness of one component (password reset in this case) will become the weakness of another (password storage). It's better to keep separate things separate and thus kind of compartmentalize their vulnerabilities (reduce impact of an exploit if you like).