There must be something seriously wrong with a.org

[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)

[rare_j]

Karlos wrote:

Genuine LOL moment there, well done!  :lol:

[motorollin]

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

[koaftder]

Either that or the site recycles hashes but does a check against the ip of the client before assignment.

I somehow ended up gaining Pirus session. I logged that out, and logged back in as me. 20 minutes later Piru ends up with my session. If thats just a random one in a billion collision, two times in 20 minutes involving the same two user account, thats highly improbable.

[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.

[X-ray]

lol Karlos

Good avatar

I deleted out about 500 sessions from the database, but honestly at this point, it's anyone's guess.  

We -- as always -- are caught between the rock and hard place between providing legacy support for the Amiga, and not being able to upgrade any farther than we already are because the authors pretty much abandoned backwards compatibility.

If anyone has any ideas, I'm all ears.

Wayne

[Louis Dias]

bah,

...birds of a feather...

:-P

[motorollin]

Wait and see what improvements IBrowse brings. It may be that an improved forum engine will work ok on 2.4 so an upgrade will be possible.

--
moto

[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.

[NoFastMem]

Wayne wrote:
I deleted out about 500 sessions from the database, but honestly at this point, it's anyone's guess.  

We -- as always -- are caught between the rock and hard place between providing legacy support for the Amiga, and not being able to upgrade any farther than we already are because the authors pretty much abandoned backwards compatibility.

I'd say you're serving two communities. The retro lot who're into original Commodore hardware, old games and demos, mod tracking, etc., and those who still want to see the Amiga become a viable desktop alternative, with an interest in PPC or even x86, off-the-shelf PCI, USB, etc.

IMO in the long run you benefit neither by holding the site back. Internet access is barely relevant to the retro scene and as for the new Amiga peeps - how many times do people use that same spiel about the Amiga doing everything they need, only to turn around and complain when site x doesn't work? What's the point in browsing the small subset of sites that are willing to compromise on functionality for what is a minority of users?

Surely it'd be better to move onwards and upwards, and hope that as one of the bigger Amiga sites, in doing so you spur on development in the Amiga browser market.

Tough love, if you will.

[Piru]

OMG, I'm me again. Lets see for how long!

[Piru]

Hey, it's me, koaftder!

[Homer]

Oh dear. Whatever next  :crazy: