> You can always achieve a token timeout by embedding a timestamp and signing the blob. What's the benefit of this over just sending a random string? One datab

> You can always achieve a token timeout by embedding a timestamp and signing the blob. What's the benefit of this over just sending a random string? One database read for the risk of an attacker being able to create arbitrary valid password reset tokens that never expire? That particular trade-off strikes me as fantastically bad, especially for an operation like password reset that doesn't happen very often. > However, because you're typically doing a password reset in a centralized database anyway, there's not really much point. Personally I find the incurred security risk more compelling than "we're hitting the database anyway, so who cares if we make another trip for the timeout."