RE: [PHP] custom session management and authentication

Oops. I meant to send it to the list... You are right. As far as security is concerned this is really just an extra layer. Probably not a ton more secure. Your point about the built-in session management looking for a URL is a good one which I didn't know about =). On Thu, 2002-10-24 at 11:07, Jaime Bozza wrote: > > Nothing. It is just hard to guess. And honestly I couldn't > > tell you exactly how much harder it is to guess, if at all. I > > think the advantage lies in that you don't pass the session > > id around on it's own. So if someone takes a look at his > > cookies or URL it might be more difficult to figure out how > > that id is generated. In my case they would see a list of > > three values. The first two are used along with a secret key > > to generate the third. Errr..like so (pls excuse syntax, this > > is adapted for better > > clarity): > > So, the hash is an md5 hash derived from some keys and so forth. That > md5 hash is constantly sent inside the cookie. This is really only > adding an additional layer of work. PHP's sessions use an md5-style > hash for the session id. The value is fairly secure and unique and not > easily "cracked", in that a person needs to have the hash to do > anything. Of course, the session_id() function allows you to set that > value to anything you want. > > Having a hash that looks up the session id isn't making anything more > secure. (Unless, of course, your session id is some simple number or id > - PHP's session_id *is* the hash, so it doesn't have the problem of > "guessing a different session" > > > A cookie is sent each time. The values are extracted. A hash > > is generated again and compared to the hash that was sent in > > the cookie. > > So, if someone has those cookie values, they can "hijack" the session > easily. Your key is in the hash that is sent. PHP's key in also in the > hash that is sent. It's pretty much the same. > > > Hehe. Yeah. I have looked some just now and it does look > > good. I think I am guilty of being a little lazy. > > Lazy? Writing your own session code couldn't be called lazy. :) > > The one thing you have more control over (at least, for right now) is > the fact that built-in session support still looks at the URL for a > potential session id. Unless you program around that (by always > creating your own session_id before the session is started), you have a > problem with someone adding the ID to the URL. With your id/hash setup, > you have an extra layer there that would require someone to have both > values, but in the case of hijacking via cookies, if someone has the one > value, they'll have all the values. (Since they're sent at the same > time, if someone's listening in on the data, it's easily attained) > > Jaime > > (I didn't send this to the list since you replied to me directly - > Wasn't sure if you wanted the convo posted through the list anymore) > > > >