5 ms·
There's really a strong reason to do this for things like user session tokens, where using crypto and avoiding database updates could easily remove a substantia
by oautholaf 12y ago
There's really a strong reason to do this for things like user session tokens, where using crypto and avoiding database updates could easily remove a substantial portion of your database traffic.
But for things that are less common, like password resets and email validation, consider the downsides:
a) using the database gives you a built in (depending on schema) audit log of these events, where a signed token does not
b) If the key is stolen in the scheme described, the person in possession of the key can hack into all your accounts. If you use database state, someone needs to have access to the database.
c) (also mentioned above) You will almost certainly be able to have a smaller token if it refers to database state, which has it's own advantages: copy and paste errors, etc
There's certainly advantages to crypto tokens/cookies, and they're the right call in some circumstances, but there's downsides to consider as well.
- adventured 12y agoSpot on. The article disregards that you really need a log of activity to check against with reset requests. Should I allow an abusive user to send 37 reset codes in 15 minutes to an email address they don't own (or even if they do own it)? Absolutely not. How else do you keep track of that activity without storing it in a database of some sort to check against?
- riquito 12y agoFor short lived things like these you can store the info you need in a memory based storage.