There must be something seriously wrong with a.org

[Karlos]

The session ID is only an MD5 hashcode at the end of the day. It has been demonstrated not so long ago that this algorithm has a collision rate several orders of magnitude greater than its theoretical limit.

Once you get sufficient users with enough login turnover, this problem can be difficult as the number of open sessions increases and with it the likelihood of collision.

More worrying is the fact that XOOPs itself uses MD5 hashcodes for various keys within its implementation.

Also, it is sometimes the case that in PHP, the session ID is passed on the URL if for some reason cookies aren't working and the page allows it (it will usually use an invisible form field in preference, if it can). If you ever see PHPSESSID=<32 character hex string> in your url, don't post it as a link ;-)


-- this post by the actual Karlos, accept no imitations!

[Karlos]

X-ray wrote:
Dude...you missed out on some opportunity for pranks there, man.
Nothing serious of course, but if it was me I would have changed Piru's avatar to a boing ball and underneath, in the location field I would write "You just got boinged by X-ray!"

 :evilgrin:  :hat:  :-P

I've been holding this one in reserve for just such an occasion:



;-)

[Karlos]

motorollin wrote:
Wouldn't increasing the length of the session ID decrease the likelihood of a "collision"? Personally I use a 128 character key as the session ID when I'm writing a web app.

--
moto

PHP itself uses a 128-bit session ID by default. Normally this should be fine, but the actual hashing algorithm itself is the problem. It just isn't as unique as first thought.

-edit-

According to the manual, PHP5 allows you to set the hash function and bits per character used for the session ID. This functionality is not available in PHP4 and I am not sure which version is used here.

Just setting session.hash_function in the php.ini to 1 would switch to SHA-1 which is a better hash function than MD5.

A second point to consider is that the database schema may also reference the session ID and expect them to be a particular type, which would complicate fixing things...

-/edit-


Your 128-character ID would be 1024-bit, assuming that every bit of the byte is used, or 512-bit if the string is a hex code. If the algorithm were poor, you could still get collisions a lot sooner than you expect.

Another thing to consider is that excessively long hashcodes take time to generate and lookup. If you have a lot of hits, you might find a fair amount of server time is spent just doing this one job ;-)

To put things in perspective, however, this is a busy site with >1000 users constantly coming and going. It has happened just this once (as far as we know) in the entire time since it has been open (spanning several years)

[Karlos]

Did Piru get your session? I thought you just got his.

-edit-

It's not generally the case that the site code itself handles session management as PHP provides an entire set of functions for this purpose. It's only when you wish to enhance the session system you'd rely on your own code and even then the chances are you'd build on top of the existing library.

-/edit-

The session is not generally tied to IP or anything else about the remote client. Some systems will match IP against session ID but it's quite unusual to do this simply because IPs can change or that several machines behind NAT might appear to have the same IP.

Consequently, 2 different machines using the same session ID will "work" at the same time, it just appears to the server as if the client is a bit "busier" than normal ;-)

Accidentally giving out your session ID as it appears on the URL is one of the biggest methods of "session hijacking". I've experimented with making systems secure against this but it is not as trivial as you might think.

The web developer plugin for firefox, for instance, allows you to edit any cookie on your system, including session cookies. In a lot of cases, if someone gives you their session ID accidentally, you can simply edit your session ID cookie for the site and "become" them.

[Karlos]

motorollin wrote:
Actually I don't know how to do sessions properly in PHP  :oops: I normally generate 128 numbers at random, check whether that combination of numbers currently exists in the users table, and if it doesn't it gets stored in the user's row in the users table. The session ID gets passed from page to page in the URL and is retrieved with $_GET[session]. The first thing any page does is connects to the database and attempts to match the session ID with a user.

I know this isn't particularly secure. When I develop something that requires a higher level of security I'll learn how to do it properly :-)

--
moto

At least use a cookie. Anybody posting a link to a page they were viewing would get their session hijacked in an instant.

[Karlos]

@X-Ray

I propose that today be named International Piru Day.
I think we should all 'become' Piru, in honour of this historic event.
Hell, I will even take a Piru avatar if enough people go along with it.

I can see a movie coming on... "Being Harry Sintonen"


(I hope I didn't mispell that too badly)

[Karlos]

X-ray wrote:
@ Homer

You have just been boinged by X-ray !!  :lol:

Kinky bugger.