4 ms·
> Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id. You should authenticate it anyway, to prevent someone from tryi
by elithrar 11y ago
> Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id.
You should authenticate it anyway, to prevent someone from trying to brute force ID generation (and therefore masquerading as another user). Otherwise all hope rides on you using a sufficiently long (CSPRNG-sourced) ID. Authenticating it is good practice.
- Vendan 11y agoAuthentication really doesn't do anything that extending your id key by that number of bits wouldn't do, i.e. a 32 byte random ID is just as hard to collide as a 16 byte random ID and a 16 byte signature. Technically, if there are any weaknesses in your signature, they may end up making your ID+signature easier to collide. Just going with a pure random ID means 1 less key that you have to keep out of source control.
- danneu 11y agoIf you don't trust your random numbers to begin with, signing one with another doesn't help you. As Vendan points out, it's worse. Just keep it simple. > to prevent someone from trying to brute force ID generation That's the point of using a large securely-random number. It's beautifully simple to give the client nothing more than a large random number to authenticate them.