4 ms·
The idea here is to take an existing protocol which previously ONLY gave the user a random 64 character hex string (representing 32 random bytes), and make it m
by CiPHPerCoder 10y ago
The idea here is to take an existing protocol which previously ONLY gave the user a random 64 character hex string (representing 32 random bytes), and make it more secure with no changes to what the user sees.
This is advantageous because such a change could be implemented without invalidating existing tokens.
> What is wrong with this simpler approach?
Now you're requiring two pieces of data where the connecting user agent only sends one. If the client is a piece of software, you're imposing a maintenance burden on them to use the new approach.
What you're calling a "convoluted" scheme ensures a smooth transition. Better security with no compatibility breaks.
- foo101 10y agoIf that's the case, then why not hash the entire token and store hash(token) in the database. Then you can just query for: SELECT tokenid, userid FROM password_reset_tokens WHERE hashed_token = :hashed_token AND NOW() < expire_time If you are worried that two tokens may collide to have the same hash, well that problem is there with your split-token solution too where token1 and token2 may collide such that token1 and token2 have the same selector and the same hash(verifier).