Why password reset tokens are sha256?

[tflori]

https://github.com/laravel/framework/blob/8.x/src/Illuminate/Auth/Passwords/DatabaseTokenRepository.php#L214

It is all about this code snippet. First we create a 40 byte random string with a 62 character alphabet (base64 - 2 characters) and then hashing it (with or without hmac does not change a thing hashing a random string will return a random string) with sha256 (16 character alphabet with 64 byte).

40⁶² = 2,126764793×10⁹⁹
62⁴⁰ = 4,962123625×10⁷¹
16⁶⁴ = 1,157920892×10⁷⁷

We are using more space (in the link; in the database etc.) and get less security. Is there any particular reason? If we want to add more security we have to send the random string and store a bcrypt in the database. The random string is already url save.

Edit: sorry, I calculated the wrong things. Anyway: the fact that hashing just increases the required space and cpu cycles remains.

[Krisell]

Are you saying or proposing that the token that is sent in the email is the same as is stored in the database?

If so, a database leak would compromise accounts. For this reason, the email should include the random plaintext token, and the database should store a hash (e.g. sha256), such that a database compromise doesn't provide any useful information about the reset tokens. Using bcrypt is unnecessary since the preimage is long and random, and I also can't see any point of using an hmac rather than just sha256. Of course, if performance is not any concern, bcrypt or similar doesn't hurt.

Edit: Laravel stores a bcrypt of the token (sent in the email) in the database. I'm not sure why the random token is run through hmac before, but perhaps in case the Str::random() can't be trusted, or just as an extra layer of security. The performance aspect is very negligible given the frequency of password resets (and the bcrypt is still miles slower than the hmac).

[tflori]

Yes, that's right. My suggestion is to use less chars for the mail (maybe 20) and store it hashed. To send the hashed version means that we store it plaintext. But md5 or sha256 are also as good as plaintext. When you have access to the hashed value it will be easy to find a collision.

[Krisell]

I'm not sure which part you said "that's right" to. Laravel does store a bcrypt in the database.

sha256 is definitely still collision resistant, and remember that the input here is a long random string which is very different from passwords.

[tflori]

Oh sorry, I meant that it is right that the token we store in DB is the same we sent via mail. But it is not. In fact it is a bcrypt of the token.

The Str::random method is using random_bytes what is cryptographically secure (see https://www.php.net/manual/en/function.random-bytes.php). The biggest problem I have with that is the size of links: https://example.com/password/reset/a20c1f276dcc5396a4f3a3e05ab0ed5cadafd9e6c2531fa480612f8b2948fd696 that exceeds most of the times (in our applications at least) the length of a line. And because of that copy paste the url (the only reason why it is not just in the action button of the mail) is much harder and less intuitive.