I'm writing my own sessions controller that issues a unique id to a user once logged in, and then verifies and authenticates that unique id at every page load. What is the most secure way to generate such an id? Should the unique id be completely random? Is there any downside to including the user id as part of the unique id?
The session ID is generated using the Random Number Generator (RNG) cryptographic provider. The service provider returns a sequence of 15 randomly generated numbers (15 bytes x 8 bit = 120 bits). The array of random numbers is then mapped to valid URL characters and returned as a string.
The session ID can be stored as a cookie, form field, or URL (Uniform Resource Locator). Some Web servers generate session IDs by simply incrementing static numbers.
Session cookies store information about a user session after the user logs in to an application. This information is very sensitive, since an attacker can use a session cookie to impersonate the victim (see more about Session Hijacking).
Go buy Bruce Schneier's Secrets and Lies and his Practical Cryptography. Go ahead and order Ross Anderson's Security Engineering 2nd Ed. while you're at it. Now, read Secrets and Lies -- trust me, it's a fun read. :) Then read Practical Cryptography. At that point you should have a better grounding in what you need to do when implementing software that needs some security. Go ahead and do your rough-draft implementation. Now that your copy of Security Engineering has arrived, read it... though that one you may want to digest a bit slower; it's a rather heavy tome.
There is also a whitepaper on web authentication dos and don'ts that is worth reading and a bit more directly applicable to what you're doing. I still recommend the books above.
And another timely article from LWN.net which lists a good number of pitfalls you need to work to avoid. (BTW, LWN.net is well worth subscribing to, and I highly recommend it. The above link allows free access to that article which otherwise would not be available to non-subscribers yet.)
If the only information in the cookie is an identifier, essentially a label, the only attack you're trying to protect from is an attacker guessing what it is. So use some random bytes. Enough random bytes that it's "unguessable."
Then squish the random bytes into something that fits within the confines of which characters you can use in a HTTP cookie. base64 works for this. It's not absolutely optimal, because there are more than 64 cookie-safe characters and it tends to leave trailing ==
characters which add bytes to the header but not randomness, but that's fine. It works and Python can probably do the base64 encoding faster than anything else we can come up with.
If you also want to prepend the user ID to it, that will make things easier to trace and debug, which will probably make your life easier, so go ahead. It doesn't give an attacker any significant advantage. (unless they manage to steal one without being able to otherwise determine what user they're stealing from, which seems unlikely.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With