Is it safe to reuse a user's hashed password as his token in the email confirmation link?

Question

The user password is hashed with bycrypt. According to this answer:

bcrypt is not an encryption function, it's a password hashing function, relying on Blowfish's key scheduling, not its encryption. Hashing are mathematical one-way functions, meaning there is no* way to reverse the output string to get the input string..

I'm not convinced it's safe. It just feels like a bad idea to expose the password hash, but I would like to avoid creating an unnecessary hash for the email confirmation and reuse the password one.

Answer 1

You're right. I wouldn't do that. While mathematically, there isn't a way to reverse a hashed password, you could continually guess passwords and see what the resulting hash is. Where there's a match, bingo.

These offline brute force attacks are even more dangerous than online brute force attacks, because the speed at which guesses can be made is many orders of magnitude faster.

If it's a simple password, it would be trivial to obtain a hash rainbow table (common passwords and pre-computed hashes). Given a hash and a rainbow table, a password could be founds in seconds.

It would be far better to generate a random, long sequence of characters that could just as easily be copied and pasted. All this link needs to do is verify an email in a reasonable amount of time. Better to keep secret things secret when given the choice.

You might also include a timeout, so that if a user puts in a dummy email, whoever owns that email doesn't "verify" it a week later. Then a user could correct this dummy email to a valid email and request another link. Any subsequent request could void the first link's ability to verify an email.

Also consider adding a link in the email for folks to click if "I didn't create this account." That will keep your records cleaner and provide a method to flag garbage accounts for subsequent deletion after a set period of time.