You're basically saying that if everything works as expected, then a signed cookie is no different than an opaque handle to server-side data. But it doesn't answer (IMHO) the point that there are more things that can go wrong with a signed cookie. IMHO, YMMV.
Here are some challenges that occurred to me in a signed-cookie approach:
1) How is the signing key generated? If it's the output of a weak PRNG, maybe it can be bruteforced?
2) Where is it stored? Hard-coded in source? Data file? Command line param?
3) Same signing key on multiple servers?
4) Do you regenerate the keys periodically?
5) What if a team member leaves. Do signing keys get regenerated?
With a DB-based approach, your session data just piggybacks on the server security infrasturcture that you would have built anyway.
You're not wrong, but note that the usual random-handle-to-server-side-state still needs good random (1) that is not correlated across servers (equivalent of 3; don't spin up VMs with the same data in the random pool!) And if you have long-lived admin sessions, you may need to think about (5) too, especially if the company does not own all the hardware that employees use.
Comments
You're basically saying that if everything works as expected, then a signed cookie is no different than an opaque handle to server-side data. But it doesn't answer (IMHO) the point that there are more things that can go wrong with a signed cookie. IMHO, YMMV.
Here are some challenges that occurred to me in a signed-cookie approach:
1) How is the signing key generated? If it's the output of a weak PRNG, maybe it can be bruteforced?
2) Where is it stored? Hard-coded in source? Data file? Command line param?
3) Same signing key on multiple servers?
4) Do you regenerate the keys periodically?
5) What if a team member leaves. Do signing keys get regenerated?
With a DB-based approach, your session data just piggybacks on the server security infrasturcture that you would have built anyway.
You're not wrong, but note that the usual random-handle-to-server-side-state still needs good random (1) that is not correlated across servers (equivalent of 3; don't spin up VMs with the same data in the random pool!) And if you have long-lived admin sessions, you may need to think about (5) too, especially if the company does not own all the hardware that employees use.