How long should a session ID be?

+1 Jesse Cox · December 24, 2014
I'm writing my site in CGI Python. However, since PHP is more geared towards the web, I think I would get a better response here.

My script generates a session ID out of a random sequence of the 26 letters of the alphabet. To avoid repetitions, I need to generate a cookie value which is long enough to be impossible to duplicate for the number of users I have.

Short and sweet:

26 ** X (where X isn't so high that it cuts into resources but isn't so low that two users get the same session ID).

Post a Reply

Replies

Oldest  Newest  Rating
0 Chris Sisco · December 24, 2014
You could store the session IDs some way and do a check to make sure that any generated session IDs do not match any session IDs that are already being used.
0 Jesse Cox · December 24, 2014
Yeah but I'd also need to prevent hackers from session hijacking. If the session IDs are too short, all a hacker must do to gain access to someone's account, is keep sending session IDs until they get the right one. Having long session IDs prevents this from happening as well.
+1 c student · December 24, 2014
disclaimer: im not a web designer, so i would not know all the details of whatever content there is in this thread.  research to validate is important.

the length of a session ID is up to you, but, as you said, requires a length which cannot be brute forced within an acceptable time frame.  for this case, you have 26 alphabetical numbers, however, you could probably try expanding that to case sensitive alphabetical characters as well as numbers from 0-9, making that a total of 62 possible combinations per character.  let's pick a random length of, say, 10, meaning there are 10 possible character spaces, include 62 possible combinations per character, that is, 62^10 (62*62*62*62*...*62, 10 times), yielding a possible key space of a number with 17 zeros (that's a lot!).  brute forcing at a billion combinations a second would take nearly 3 decades!  if you increase the length to 15, that's almost the number of atoms in a human body.  brute forcing such a number at the same rate would take almost 2.5 centuries! :O 

back to the topic, length plays some part of security as i have just demonstrated however, generating a session could be a bit difficult if (which i am assuming ) you are using a standard psuedo-rng function you just pulled out of the documentation, meaning it is predictable and can be replicated to some extent given initial conditions. to counteract this, you can input a number of variables such as a computer's fan speed, x-y cursor movements on the screen, etc to generate a more "random" number which would be much less predictable.  another problem is where a malicious user can steal a session id in some way.  if they happen to obtain this session id and it is in its original form, session hijacking would be a cinch.  to prevent this, you would need some sort of hashing algorithm to hash your session id before distribution so that anyone who may encounter an id cannot directly inject it, thus serving as an authentication method.  as a side bonus, any length id would then yield a same length hash, therefore, giving you some room in case you need to increase the length of an id with almost impossible clashing, given the correct algorithm (such ash SHA-1).

i have probably merely touched the surface of your security issues and this is just session id.  do some research on the things i mentioned above and more to see what other vulnerabilities there are.
0 Chris Sisco · December 25, 2014

c student:
disclaimer: im not a web designer, so i would not know all the details of whatever content there is in this thread. research to validate is important.

the length of a session ID is up to you, but, as you said, requires a length which cannot be brute forced within an acceptable time frame. for this case, you have 26 alphabetical numbers, however, you could probably try expanding that to case sensitive alphabetical characters as well as numbers from 0-9, making that a total of 62 possible combinations per character. let's pick a random length of, say, 10, meaning there are 10 possible character spaces, include 62 possible combinations per character, that is, 62^10 (62*62*62*62*...*62, 10 times), yielding a possible key space of a number with 17 zeros (that's a lot!). brute forcing at a billion combinations a second would take nearly 3 decades! if you increase the length to 15, that's almost the number of atoms in a human body. brute forcing such a number at the same rate would take almost 2.5 centuries!  

back to the topic, length plays some part of security as i have just demonstrated however, generating a session could be a bit difficult if (which i am assuming ) you are using a standard psuedo-rng function you just pulled out of the documentation, meaning it is predictable and can be replicated to some extent given initial conditions. to counteract this, you can input a number of variables such as a computer's fan speed, x-y cursor movements on the screen, etc to generate a more "random" number which would be much less predictable. another problem is where a malicious user can steal a session id in some way. if they happen to obtain this session id and it is in its original form, session hijacking would be a cinch. to prevent this, you would need some sort of hashing algorithm to hash your session id before distribution so that anyone who may encounter an id cannot directly inject it, thus serving as an authentication method. as a side bonus, any length id would then yield a same length hash, therefore, giving you some room in case you need to increase the length of an id with almost impossible clashing, given the correct algorithm (such ash SHA-1).

i have probably merely touched the surface of your security issues and this is just session id. do some research on the things i mentioned above and more to see what other vulnerabilities there are.


Some good ideas here!
0 Jesse Cox · December 25, 2014
I would also imagine the chances increase every time a session cookie is created (am I correct or seeing something completely off?). So two session cookies would mean that instead of say 1/100 chance, you then have 1/50. 4 users would make it 1/25. Where it would be x/(62**10), X being the number of sessions in existence. I know it cuts the security but does it make a difference?
0 c student · December 25, 2014
sorry, could you clarify what you mean by the increase of chance??
0 Jesse Cox · December 25, 2014
With each additional session ID created, the chance of a brute force attack succeeding has increased. It no longer becomes 1 in a billion. It's 2 in a billion 3 in a billion etc. Basically allowing the attacker more wiggle room.
0 c student · December 25, 2014
brute forcing means that they try EVERY single possible combination.  if you hash your session id, any length id will output a same length hash, i.e. if you have a variable length, the hashed length will be the same.  this means the brute force will have to go through single character length, double, triple, quadruple, etc (if they are smart, they obviously won't do anything less than maybe 6 characters in length).  with length of 6 to length of 15, the key space is still incredibly impractical to work with (62^6 is 56800235584 possible combinations, 62^15 is 7.69*10^26 combinations).  hashing is a one-way function, meaning they cannot be decrypted, the only way to find the hashed session id is, you guessed it, to brute force all possible combinations until you find the exact hashed output.  if you have a static length session id and the attacker knows the length, you are in deep trouble.  another possible way to prevent session id hijacking is to expire them.  once expired, they will be useless to anyone.
  • 1

PHP

107,187 followers
About

Server-side, HTML embedded scripting language used to create dynamic Web pages.

Links
Moderators