Security trade-off when using low number of rounds with SHA256 I have a web application that stores hashed password reset tokens in a database table. The tokens are randomly generated 256-bit values. I'm currently using Python's passlib sha256_crypt function to hash the tokens which defaults to using 535000 rounds. 

In order to speed up the hash computation, I'd like to decrease the number of rounds that the sha256_crypt function uses going forward. Passlib allows you to choose a rounds value between 1000 and 999999999, inclusive. Given that I'm hashing random 256-bit values, would it be safe for me to decrease the number of rounds to as low as 1000? Would there be any serious security trade-off from doing so?
As described in the comment, lets assume the password reset tokens is one-time token generated when a user requests its password. 

The PBKDF (salt hashing in the loops) is used to make the password guessing much more expensive in case the database is compromised. The whole problem of PBKDF is based on observation that the user passwords are having low entropy.


  Given that I'm hashing random 256-bit values, would it be safe for me to decrease the number of rounds to as low as 1000? 


Lets assume that the password reset token is plain. 
The worst case what can happend is that the attacker (having read access) could reuse an existing reset token or create a new one (requesting a new password). 

So you need some hashing to hide the original token value, but if the reset token is having enought entropy (is random and long enough) you would be ok with a simple hash. The length and randomness would deny the dictionary guessing process instead of expensive PBKDF function.