There was some discussion in a thread a few days back[1] in which I asked a similar question. It boils down to "possible, but very easy to screw up, and for wh

There was some discussion in a thread a few days back[1] in which I asked a similar question. It boils down to "possible, but very easy to screw up, and for what is probably relatively small benefit." The only benefits I can think of for the info-in-token approach are: * Less database hits to validate a token. Given that password resets are probably only a small part of your site load, I'm dubious as to the utility of this optimisation. * No server-stored tokens to secure - If an attacker manages to dump or partially break your database (SQLi, logic bug, whatever), they could extract the reset tokens and use them to gain access. Obviously, a full db exploit would make this unnecessary, and a proper reset implementation (that expires the tokens after use, sends confirm emails on use, etc) means unauthorised use would hopefully be detected. In the info-hash-token, the only place it's ever actually stored is in the user's mail-box (and every email server involved in the process along the way, potentially), which might reduce the risk of disclosure, especially bulk (server dump) disclosure. Any other advantages I might have missed? It's possible to do things like token expiry, invalidate on use, invalidate outstanding tokens using hashed tokens, but all of those things are fraught with danger. [1] https://news.ycombinator.com/item?id=5033266 https://news.ycombinator.com/item?id=5033266