Storing password reset token in DB - what are the implications?

Question

In multiple systems I've built/supported I've seen user management do the following for password reset: generated a password reset token via some hashing method and email the link with token to user. Usually there are bits of information included into these tokens - user id, user security stamp, date, server name or machine key (I'm going with ASP.Net Identity framework now). When user follows the link with token, framework follows the same process to rebuild the token and compares the token with user-provided one. If tokens match - allow for password reset.

A lot of time machine-related parts of token change from the moment of token generation to the moment when user uses that token. I.e. IIS restarts and this can invalidate token in some cases. When web-application is spread on multiple servers (i.e. web-farm), chances of this token to be invalid are higher (i.e. machine keys are not synchronised between machines, etc.).

Now I'm considering a scenario where I store the generated token in the database, add a generation timestamp. And when user comes back with the token, I don't re-generate the token, but rather compare the stored token, validate the timestamp and allow/disallow password reset.

Given that token now becomes a password (though time limited), for a good measure I can treat it as password and store hash only.

I can't think of flaws in this scenario, but I'm sure there some. Given the implementation of this scenario is solid, what other issues might arise from storing the tokens?

Answer 1

Store (user_id, expiration_time, hash_of_token). If hash function used is secure and tokens are unpredictable (with at least 128 bits of entropy), then there is no way for someone else to generate a valid tokens even if the attacker had read-only access to the database.

Specifically the hash function has to be resistant to preimage attacks. (SHA-2 and several other algorithms qualify.)

If the entropy behind randomly generated tokens is small then someone with read access can brute-force test preimages and potentially recover the token. Someone could also brute-force test potential tokens online (subject to rate limiting) with some probability of success dependent on how much entropy the tokens have and how many candidate tokens they can try.

High min-entropy inputs can be hashed with ordinary secure hash functions because it's not possible to test every possible input. Passwords, however, should be hashed with a dedicated password hashing algorithm (Argon2) because most passwords have very low entropy.

Those database fields, a CSPRNG, and a preimage attack resistant hash function are all that's strictly necessary, but see Secure Account Recovery Made Simple for additional information.