How is a session_id generated?

jjonje

Just curious about how a session id is generated?

Weedpacket

A quick look at the relevant source code (the function php_session_create_id()) says it's an MD5 of the client's IP, the current time (in microseceonds, if they're available), an internal RNG, and (if you've specified one in your configuration) bits from an external source of entropy.

jjonje

Thanks! I was just curious because I am storing sessions in a mySQL table and when I destroy a session the values were deleted in the table accordingly but when a new session was generated it was using the same value as the previous session id. I found that I had to delete the cookie along with destroying the session in order to generate a different session id the next time I accessed the site.

jjonje

Weedpacket, (or whoever)
If session id's are generated from microtime then how is it possible that one of my customers session id's is exactly the same as another customers when they were on the site on 2 different days?

Weedpacket

Originally posted by jjonje
Weedpacket, (or whoever)
If session id's are generated from microtime then how is it possible that one of my customers session id's is exactly the same as another customers when they were on the site on 2 different days?

How do you know they were? Have you verified this? Sounds highly unlikely, unless session IDs were somehow leaking out from one customer and ending up being given to the other. More likely, your use of your database (or whatever you're using to maintain data over day-long periods) is buggy, and one customer's data is being associated with the other customer.

jjonje

Yes I have verified this. I started using the code found on Zend (http://www.zend.com/zend/spotlight/code-gallery-wade8.php) to store sessions in a table because of this problem. I keep track of customers items in a carts table with the session id. When they make the purchase the session id is stored in an orders table along with an auto-incremented order number and the session is destroyed along with the cookie. I have verified that 3 completely different customers in the past 3 days have logged the same session id in the orders table.

All I would like to know is: If session id's are generated with some kind of timestamp how is it possible that this can happen? Doese my host have some settings wrong?

fizzwizz

The weak link is the md5 hash

unfortunately md5 is not an encryption it is a hash. The difference is that an encryption is unique therefore decrypting an encryption produces the original term and the original term only.
A hash is different, a hash cannot be decrypted as it bares no resemblence to the original term

eg .. a simple hash could be the first letter of the word as a numerical value

eg the hash of "Apple" would be 1
The hash of "Car" would be 3

The problem with a hash is that the word "Crazy" also has a hash of 3 .. so is NOT unique.

The MD5 hash is far more sophisticated but still does not produce a unique string.

This being said the odds in your case would be phenominal ... perhaps you should buy a lotto ticket 🙂

Weedpacket

Originally posted by fizzwizz
This being said the odds in your case would be phenominal ... perhaps you should buy a lotto ticket 🙂

Indeed; no-one has yet found two strings that collide under MD5. Either in the wild or under laboratory conditions. They certainly exist, but so do identical snowflakes.

fizzwizz

Originally posted by Weedpacket
Indeed; no-one has yet found two strings that collide under MD5. Either in the wild or under laboratory conditions. They certainly exist, but so do identical snowflakes.

This raises an interesting feature about MD5,
Let's imagine a set of strings composed of every permutation of characters used on a conventional keyboard up to 32 characters in length. Let's call this set X which includes every possible password string up to 32 characters long.

It is fair to assume that this set will have been the first to be tested under laboratory conditions and yielded no collisions.

Knowing this means that by restricting solutions of the MD5 hash to the set X will provide UNIQUE solutions. In this regime the MD5 hash becomes and encryption and is, therefore, decryptable.

Interesting!

laserlight

Let's call this set X which includes every possible password string up to 32 characters long.

Note that the number of elements in X is greater than the number of possible MD5 hashes.

It is fair to assume that this set will have been the first to be tested under laboratory conditions and yielded no collisions.

Of course, even if one did restrict the number of elements in X to 2**128, there may be collisions for the given set.

Knowing this means that by restricting solutions of the MD5 hash to the set X will provide UNIQUE solutions. In this regime the MD5 hash becomes and encryption and is, therefore, decryptable.

Though such a scheme would be quite useless, since all the possible plaintext is known, and is immediately associated with the 'ciphertext'.