How do I verify a reset token if the token is hashed in DB?

Question

I've been searching around the web for best practice how-to on secure password reset system (email with reset url), and the idea to hash the token in the database, which I did not implement at first, seems to be the the most secure way to store the token.

Im currently following this guide, and he does not mention it (why?)

Im using bcrypts for password hashing allready, so thats what im using for this aswell.

How ever, the syntac for the verify is like this: Bcrypt.verify(non-hash, hash);

So my question is this: If the reset-link only contains the token (which is not in db, the hash is) - how can I find the user in the db?

is it safe to append email/userID to the reset-link as well? None of the other services Ive seen have does this (afaik), only the token (do they not hash the token in the db?).

I dont want to make my own scheme that will create a security issue, so how do I proceed with this ?

Using asp.net web forms and c#

Answer 1

I was pondering this as well and it was hard to find answers.

My solution: don't hash the token with bcrypt. Instead hash it with e.g. SHA256 with no salt. It will be secure enough if the token is truly random data and long enough.

Then the hash will always be the same, so you can easily find it in the database. No need to iterate over all users or tokens in the database – that would be madness.

Some resources to validate my solution:

• How to store the access token / password reset token in the database?

• Pre-generating 'secure tokens'

• Should password reset tokens be hashed when stored in a database?

Answer 2

You need one property for your token and one for your hash. The reset token must be unpredictable. The hash of the token must be preimage resistant.

To make an unpredictable token you can take 16 bytes from something like /dev/urandom. Or any RNG with equivalent security properties. (Java's SecureRandom, Python's os.urandom, .NET's RNGCryptoServiceProvider, etc.) If an attacker can guess the next token she can change a person's password without needing to read the account owner's emails.

Preimage resistance is needed for the token's hash. Otherwise someone with read access to the reset token list (admins or hackers) can compute their own token that matches the hash. You should replace BCrypt with SHA-2 when you aren't hashing things like passwords.

The purpose of BCrypt is to stretch low entropy passwords. (Meaning relatively predictable.) If passwords always had high entropy then you could use any preimage resistant hash. The goal of BCrypt is to slow down everyone's guess-and-check speed for passwords and hashes... but normal cryptographic hash functions could be orders of magnitude faster than SHA-2 and still be un-brute-force-able if the input entropy is high. (This is why you generate a long unpredictable token. 16 bytes from urandom should give unpredictability equivalent to 128 bits of entropy.)

DO NOT base which account's email you reset off of client provided data! Put the token, expiration time, and userid all in the same database entry.

Do use a library that implements password management for you. You can use what you learn about cryptography to judge if a library is secure or not, if you learn more, but it will take a much deeper understanding of topics in security and cryptography before you can implement your own system correctly.