3 ms·
Why is the author using a convoluted scheme of splitting token into selector and verifier, and then storing hash(verifier) in the database, why not use a simple
by foo101 10y ago
Why is the author using a convoluted scheme of splitting token into selector and verifier, and then storing hash(verifier) in the database, why not use a simpler scheme of accepting username and token from the user and storing hash(token) in the database?
In other words, my question is: Why do you need to split the token at all? Why not store the hash of the entire token in the database?
So now, the username of the user becomes the selector, and the token becomes the verifier. What is wrong with this simpler approach?
- CiPHPerCoder 10y agoThe 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).