Hacker News new | past | comments | ask | show | jobs | submit login

> 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.

Authentication 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.

If 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.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact