"How unique" is a session ID?

[dagon]

i would not use the session id, i would create a transaction id (int, auto increment, unique) and store that in the session.

MOD EDIT: The post by Square1 is actually the first post of this thread; dagon's post is actually a reply to Square1.

[Square1]

Hi All:

I know this is a loaded question and I did a Google search on this as well, but "How unique" is a session ID?

I have 2 tables in a shopping cart. An order table and a second table that lists the items in that order. The two tables are joined via the session ID. This is working fine. My concern is that down the road, someone will place an order and the session ID they get will be a dupe of a session ID from an earlier order.

Now I know this is POSSIBLE, but is it as possible as winning the lottery 2 weeks in a row kind of thing. Is it so unlikely that a dupe session ID will come up for the user who happens to be placing an order on my site (vast majority do not) that it is HIGHLY unlikely and not worth worrying about.

I could take the session ID and modify it after the order is completed if I need to, but if the consensus is not to worry about it then I won't.

Thanks !

[traq]

I think (can't find documentation) that PHP verifies that any given session id is not in use before using it.

Therefore, collisions shouldn't be a problem unless you are saving sessions for subsequent user logins (which would mean you're storing them in your DB, so you could institute your own check before allowing them to be used - in fact, you could do that anyway).

[laserlight]

Square1 wrote:

Now I know this is POSSIBLE, but is it as possible as winning the lottery 2 weeks in a row kind of thing.

According to this webpage:

Your actual odds of winning the lottery depend on where you play, but single state lotteries usually have odds of about 18 million to 1 while multiple state lotteries have odds as high as 120 million to 1.

If we assume that the pseudorandom number generator (PRNG) behind it is sufficient, then with MD5 hashes taken there are 2¹²⁸ possible session ids, where ^ denotes exponentiation. Again, making assumptions about the PRNG, each of them would be equally likely. However, because we are just considering whether any two session ids generated might match, the birthday problem applies, so the probability is about 1 in 2^64... which makes those tough stake lotteries look easier to win than a game of guessing a coin toss (120 million is less than 2^27).

Of course, in practice both the PRNG (or even a "true" RNG) and/or MD5 (or SHA-1, etc) are not that good, but still.

[Square1]

OK, so this means if I get a dupe session ID I should run out and buy lotto?

LOL! Thank you for the analysis.

[dalecosp]

Perhaps the issue here is what is appropriate and by design. The PHP session ID is meant to be a temporary means to identify a client. It's not designed to be stored as a permanent record.

The vast majority of e-commerce sites, would, I think, expect to crib a little user data during the checkout portion of the transaction, at the very least.

With that in mind, I'd follow Dagon's suggestion and store transactions with their own db-generated unique id and keep some piece of user ID in there as well (email address, maybe?)

The next time the user logs in, you've got his entire transaction history available.

[bradgrafelman]

For a simple alternative on MySQL, consider the UUID() built-in function.

[Square1]

bradgrafelman;10988243 wrote:

For a simple alternative on MySQL, consider the UUID() built-in function.

"Simple alternative" are the magic words! That was the reason I used session ID in the first place!

[Square1]

bradgrafelman;10988243 wrote:

For a simple alternative on MySQL, consider the UUID() built-in function.

Is UUID session based? Will the same UUID code carry through with the session or do I need to set it as a variable?