...

View Full Version : Sessions... why bother?



krycek
03-26-2003, 01:23 AM
I've been thinking about sessions. I've 95% completed version 2.0 of my SO_SECURE user authentication and authorisation scripts, and at the moment they use ordinary cookies. (Oh, and that's fine, because the scripts are pretty much unhackable ;))

Thing is, I was considering adding an option to use sessions - but, what's the point???

I mean, I can store data in a cookie just fine, without the hassle of sessions. And, even with a session you have to store your session ID in a cookie (or else carry it with you inthe URL - which I hate!) so you are still dependant on cookies.

The way I see it, a properly coded script can be just as secure using cookies as it can using sessions - perhaps more so.

Has anyone got any thought on this? Anything I am missing? :confused:

::] krycek [::

PS - I will be releasing SO_SECURE soon, if anyone wants to help test it please email me: krycek @ soapi . com :D

stoodder
03-26-2003, 02:03 AM
lol tell yuo the truth i dont know ive made my own scipting stuff to by using cookies lol but i think it is because cookies like that can be read with programs and hackers can get cookie grabbers and actually nab them directly off of your computer, wich they ocould read or even copy into your directory so tat you can use that cookie for however long it is left.. i dont think with sessions it stores al lthat info or it like encyptes it but im not sure.

krycek
03-26-2003, 02:12 AM
well... actually cookies can be more secure than sessions.

see, if you store your session id in a cookie, you may as well use cookies. after all, session cookies are a little more fiddly, and more crucially, are not persistant.

however, if you use URL session id, that leaves you open to attack - someone need only know the url with the active session id, and they can get in... and IP blocking is not an elegant option due to dynamic IPs and proxies etc.

see, with an ordinary cookie I can control it easily and make it totally secure, and pretty much invulnerable unless you get someone with a lot of time and computing power - and of course, perseverance ;)

with sessions... well, I can't think of a reason for using them right now, hence this thread.

::] krycek [::

Spookster
03-26-2003, 02:13 AM
What you are missing is that sessions will still work with cookies disabled. Session information is stored on the server with the users session id. By default it will create a cookie in the browser with a matching session id. If cookies are disabled then it will use url rewrite automatically and carry the session id transparently through the URL unless of course you wish to do it manually and make it visible in the URL.

Plus they are much more secure than using client side cookies only where you store the data in the client side cookie. A person would very modify the information in the cookie.

krycek
03-26-2003, 02:41 AM
Hmmmm, transparently? I must say I haven't seen that...

Yup sessions will work without cookies however is that a good thing as far as security goes...? I think I would rather play with the cookies... hmmmm

see, a person could modify the cookie, yes, but that would not matter if the script was coded well. Whereas, there is scope to steal session ids from the url, and that is something you cannot very easily get around, unless you use cookies... and then you remove the #1 reason for sessions in the first place.

Hmmmmm.

::] krycek [::

krycek
03-26-2003, 04:12 AM
Originally posted by Josh Campbell
I never use sessions myself. It is way too insecure. Even the PHP manual says "Sessions are not reliable as a secure authentication mechanism". If someone gets the session ID (which can be sniffed), they steal the session. Cookies aren't really all that secure either but they're easier to use and understand.

thanks :thumbsup: it's good to know I haven't got my head the wrong way around about this :)

::] krycek [::

Spookster
03-26-2003, 04:38 AM
Originally posted by Josh Campbell
I never use sessions myself. It is way too insecure. Even the PHP manual says "Sessions are not reliable as a secure authentication mechanism". If someone gets the session ID (which can be sniffed), they steal the session. Cookies aren't really all that secure either but they're easier to use and understand.

That's your opinion and not a fact fortunately. Insecure as compared to what...client side cookies? lol If you use sessions properly then they will be as secure as you need. If you are working with sensitive information such as credit card numbers or other personal info then obviously you should be working with SSL so your sessions should be encrypted. But for other purposes sessions are just fine assuming you don't do something silly like store passwords and stuff in the session or set your garbage collection intervals to be really huge.

How are cookies easier to use than sessions?



<?php

session_start();
$_SESSION['name'] = 'Spookster';


echo "Hello " . $_SESSION['name'];

?>


that's not very hard to do. In three lines of code I created a session, stored a session variable and then used the session variable.

Íkii
03-26-2003, 09:43 AM
I always use sessions - for simplicitys sake - over cookies

They are also faster as XXbytes of cookie information doesn't have to be sent/retrieved for every page view - 'specially as upload speed is often very slow

Also - to lower the chance of session theft even further I construct client header strings and test against the session-instantiated version

$_SESSION['client_string'] = $_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'];'
.....
if($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'] !== $_SESSION['client_string']) {die(''#$%^");}

or such - so the only way you could pinch a session is by sending the same user agent and ip string as the session you're trying to pinch. Only use that for admin panel stuff though.

firepages
03-26-2003, 03:04 PM
"If someone gets the session ID (which can be sniffed), they steal the session."

despite the stuff in the manual it really isnt that easy to hijack a session, sessions are far more secure than cookies and as Spooks mentions easier to use , + the guarrentee that anyone can use the site regardless of cookie settings.
(check out trans-sid for transparent session info)

I really can't actually think of 1 good reason to use cookies when you have session support available.

Note that by setting the using
ini_set("session.cookie_lifetime",time()+$whatever");
you can in fact make the session cookies persist as long as you wish , though this is best used in association with a custom session handler to stop garbage collection from deleting your session data (though simply serializing & saving the session can also help here) .

Krycek , sessions + serialize()/unserialize() can be your very best friends , honest ! :)

missing-score
03-26-2003, 03:38 PM
That example that spookster gave, will it remain a variable on future pages, so like:


<?php

session_start();

$_SESSION['user'] = 'Whoever';

echo "Name: ".$_SESSION['user'];

?>

<a href="link_to_other_page.php">Link</a>

Could I then put:


$_SESSION['user'];


on the next page and have it write the user? Does it remember the info without passing it through the address bar?

Galdo
03-26-2003, 04:36 PM
Yes it does as long as you use session_start() first.

brothercake
03-26-2003, 05:03 PM
Originally posted by Josh Campbell
If someone gets the session ID (which can be sniffed), they steal the session.

Surely session IDs are dynamic - hence a different visitor who knows a session ID won't be any better off, because that ID is unique to one client/session?

krycek
03-26-2003, 06:05 PM
ok, here's an example. currently, my security script stores username and password (encrypted) in a local cookie.

Every single time a page is loaded, the details are re-checked (a basic security requirement)

This, as far as I can see, is extremely secure, especially as I use a custom encryption routine.

Now, the data itself (username and password) would arguably be just as secure if sessions were used - or, perhaps more so, seeing as the values would be invisible to the user.

However, to be totally secure, that session's ID would have to be stored in a local cookie. And, if you are using cookies, why not simply use cookies alone, and not sessions...? There are a few advantages to cookies, over sessions. The first is persistance, and guaranteed "samenesss" i.e. you are using the same cookie every time, whereas there is some scope for mix-up with session cookies. This does not apply *too* greatly to my script, because the inactivity timeout is usually 10 minutes.

The second thing is that although cookies are vulnerable to the local user's sabotage, they are pretty secure from other users.

Unlike sessions - if we are not using cookies, then it is possible to detect the session ID, and use it, hence hijacking the session. It doesn't matter that the values are invisible - they are in use anyway, because of the session id.

I think there are for and against points for both. I created this thread to provoke discussion, to help me make up my mind whether I should code session support into my script. I now think that I should, because there are some good arguements for doing so, even though I personally don't like using sessions.

Keep it up! :) Debate is good... :D

::] krycek [::

firepages
03-26-2003, 06:44 PM
aye debate is good !

so is control , if Spookster as a happy hacker (only rumours I know ;)) decides he wants to try and circumvent your security , and realises that cookies are in use ... then the first part of his work is already done for him, i.e. a quick look in the cookie jar will let him know what variables he has to use to try and break in , he may also get an idea of the encryption used to do so.

Remember that encryped passwords are no safer against brute-force if the encryption is known or guessable (MD5 etc (especially if no salt is used)).

Of course he still knows nothing about how that data is implemented and of course if you are aware of security concerns then you will have most angles covered and properly implemented it would be hard to break in with just that information alone ... but its a start.

The only information that a session cookie reveals is that sessions are in use.

OK granted thats a giveaway in itself as the happy hacker can now poke around to try and read the session temp directory where session data may be held unencrypted, but we have to assume that the server is a little tighter than that else we are in trouble anyway :) .

The other aspect of cookies are that they are on your clients machine & therefore out of your control, anyone who uses that machine has access to the cookies , anyone with a little activex or various exploits can try and grab that information, OK thats a brower issue and not cookie specific , but still an issue non-the less.

Yes the sessions force you to login to the system every time you visit (unless you make the session cookies persist) but really if the application data is in any way important then that really should be enforced anyway.

but the above aside I would recomend sessions anyway , storing login and other data is only part of it, for shopping carts , form persistance etc etc I find sessions invaluable, especially the ability to pass objects from script to script etc, I personally use cookies now only for non-essential data , i.e. remembering someones name or whatever when they come back to the site or traffic-tracking etc.

thats my 2.5c anyway!

missing-score
03-26-2003, 09:31 PM
I agree with firepages.

I used to use cookies, in fact I hadn't really used sessions much until this thread. But they now seem priceless.

I did know that they were not so secure, but at the time, security wasn't too much of an issue. I have just 'lent' my forum to a mate while I re-write it, and I will be using sessions this time.

Also though, It's not like you have to write page after page of code for a session to work. Although they require a little more scripting usually, You are not creating alot of work for yourself.

I also think that sometimes the reason that you dont use certain programming function is because you may not know much about it (not offending anyone). Its just that before I knew that sessions could pass information through the browser without it being in the address bar or cookie, I avoided them.


So in my opinion, Sessions are a better choice than cookies, although I do agree that cookies are also a valuable resource.

mordred
03-26-2003, 10:13 PM
krycek, there is security concern in your handling of storing the username + password in the cookie itself (even if it's encrypted). Because cookies are transported as plain text, someone sniffing the network traffic could gain access to the cookie's data. He would be able to login to your secure area sometime later because he has could send the information stored in the cookie from his computer. Unless your encryption algorithm includes some kind of timeout checking, that is.

Session ids do expire. Plus they are usually implemented as very hard to reengineer, so you have to act very quickly once you hijacked a session id so the session does not expire. That probability is quite small if you set the session_timeout reasonably low. Occasionally, the user would experience a session timeout and forced to re-login, but that's a small price to pay IMO.

Storing the username + password in a cookie is considered as a no-no, see also the beginning of chapter 7 of the OWASP guide (http://www.owasp.org/guide/).

krycek
03-26-2003, 10:33 PM
mordred, I am aware of that... I did mention that I encrypt the data ;)

basically I run the info through a one-way encryption routine, the output of which then gets stored in the cookie. So, all you would see is useless garbled text :)

to authenticate, the user types their username and password in, and yes they travel in plain text of course (unless using https) but then get encrypted server-side, and compared with the db (I store the encrypted passwords, not the plaintext ones)

by taking such simple steps, the threat of being hacked is brought virtually to zero - the only threat now is that of brute force, which is always a threat :p

however I also have a built-in facility that only allows a set number of false logins over a period of minutes

now, I could achieve exactly the same by using sessions, and indeed I am going to add sessions as an option in my script. However I do not see how my method is in any way insecure - quite the opposite :D

::] krycek [::

PS - AFAIK my SO_SECURE scripts have never been hacked yet! :D ...and my just-completed version 2 is better still... :p

Darknight
03-27-2003, 02:24 PM
PS - AFAIK my SO_SECURE scripts have never been hacked yet! :D ...and my just-completed version 2 is better still... :p [/B]

It's great thay your system has never been hacked.

I wonder though... has anyone tried?

krycek
03-27-2003, 03:31 PM
yup, they sure have...

when I coded version 1, well over a year ago, I ran a challenge on one of my sites at that time, to see if anyone could hack in.

very simply, the challenge was to hack in and add some information to the database using the admin system.

From my logs at the time, over a period of one month while the challege ran, there were over 200,000 attempts, from over 1,000 IP addresses. In fact, that particular site went up in popularity so much that it went up to over a million visitors per month for a while. I had to move it onto its own server and everything! lol :p

See, because my security system is multi-level, even if someone found a valid username and password combo to use, they could not do admin stuff without having the required level of access level clearance. There is no way to externally set that level - only from the database. Also, brute forcing would not work because you have to have cookies turned on in order to log in successfully, and at the same time your false attempts will be logged and you will be banned for 5 minutes if you have more than 3 false login attempts within that period.

So, with all the layers of security, no-one ever managed to hack in and complete the challenge... I guess the $50,000 reward I put up was an encouragement though ;) hence the number of tries :D

::] krycek [::

Spookster
03-27-2003, 03:39 PM
yeah right!! :rolleyes:

brothercake
03-27-2003, 06:59 PM
Originally posted by krycek
brute forcing would not work because you have to have cookies turned on in order to log in successfully, and at the same time your false attempts will be logged and you will be banned for 5 minutes if you have more than 3 false login attempts within that period.
My brother wrote a little tool that lets you define its UA string, accepts cookies, generates any kind of content-accept header, supports multiple versions of HTTP, and continually changes its apparent IP address.

Shift4Sms
03-27-2003, 08:35 PM
::] krycek [::,

Sorry, I have nothing useful to add to this thread. I just wanted to chime sympathetically to your diary -- :eek: -- Just be glad it's not triplets -- :eek: :eek: :eek:

While I had more of a notice, it was just a shocking!

Good luck...

missing-score
03-27-2003, 09:03 PM
The way I see it is that, no matter how secure something is, there will be a hacker somewhere that will be able to get access somehow, such as people that have hacked microsoft.

Also, you seem to find that hackers will try and attack something that is supposed to be secure, to prove themselves sorta thing.


This is why I think sessions are much safer, because even if it does take alot to hack something, it will be possible, and is therefore advisable to use the safest method possible.

krycek
03-27-2003, 09:38 PM
Originally posted by Spookster
yeah right!! :rolleyes:

um, spookster, I kinda feel like I'm completely missing your point here...? :confused:

to what are you referring?

::] krycek [::

krycek
03-27-2003, 09:40 PM
Originally posted by brothercake
My brother wrote a little tool that lets you define its UA string, accepts cookies, generates any kind of content-accept header, supports multiple versions of HTTP, and continually changes its apparent IP address.

sure, if you use such a tool, after a while brute forcing will work. But, that's the same with just about any system, and your brother's tool would do the same thing with sessions, yeah?

And, he would still not get very far unless he hacked an admin account.

::] krycek [::

krycek
03-27-2003, 09:44 PM
Originally posted by missing-score
The way I see it is that, no matter how secure something is, there will be a hacker somewhere that will be able to get access somehow, such as people that have hacked microsoft.

Also, you seem to find that hackers will try and attack something that is supposed to be secure, to prove themselves sorta thing.

yup, I totally agree with you there :) that's the reason I had the sponsored challenge - to promote the site at the time, and also to give my scripts a real test.

The point is not whether a system can be hacked - all systems can be hacked. The point is to make it as difficult and time-consuming as possible :)


This is why I think sessions are much safer, because even if it does take alot to hack something, it will be possible, and is therefore advisable to use the safest method possible.
Um, I still don't quite agree with sessions being all that much safer. But that's kinda what this thread is all about :)

::] krycek [::

krycek
03-27-2003, 09:45 PM
Originally posted by Shift4Sms
::] krycek [::,

Sorry, I have nothing useful to add to this thread. I just wanted to chime sympathetically to your diary -- :eek: -- Just be glad it's not triplets -- :eek: :eek: :eek:

While I had more of a notice, it was just a shocking!

Good luck...

Cheers! :) there's a thread here (http://www.codingforums.com/showthread.php?s=&threadid=17032) which I made about it :)

::] krycek [::

brothercake
03-27-2003, 09:56 PM
we've got the most experienced PHP coders on this board saying sessions are safer.

krycek
03-27-2003, 10:44 PM
Originally posted by brothercake
we've got the most experienced PHP coders on this board saying sessions are safer.

not all of them...

anyway, doesn't it depend on your implementation?

In any case, I said "I still don't agree..." - I did not say that I don't agree, either. I've heard enough to make up my mind to include session support, however I am still undecided about how truely safe sessions are, compared to ordinary cookies, in various configurations. :)

::] krycek [::

firepages
03-28-2003, 03:24 AM
Ok , encryption ... its irrelevant here , if someone already has the cookie then the password may as well be plaintext .. its a bad idea to place passwords in cookies fullstop , encrypted or otherwise makes little difference , the cookie itself is as good as a password.

So the main issue for me still is above + the fact that you are placing half of your security in your users hands. If they get hacked on IRC,MSN or have a trojan hidden away somewhere or are on a vunerable network (i.e. any win32 computer connected to the internet ;)) then your cookie is available to any who wish to play.

If your data is not mission critical like say a BB then thats fine , but for anything else you are asking for trouble.

Otherwise again your cookies give away information that the potential hacker could not otherwise know , what encryption method you use , perhaps the cookie names are representative of the login fields ? I dont know , I do know that with session variables this information is not so easily come by , useful or otherwise.

As Brothercake noted its easy to get past '3 strikes and you are out ' login challenges , IP's and REFERER's etc are easily spoofed I can utilise existing scripts or write my own that do nothing all day but attack your script and a cookie based system will never know , only your logs will show the attempts. I think we both know that anyone that interested would be trying to compromise the server directly but thought I would mention it anyway.

But to be fair I think that the security issue here is more the fact that your passwords are persisting , so this is not so much entirely a cookie issue more one of the methodology employed.

krycek
03-28-2003, 04:01 AM
hmmm, interesting explanation and I do agree. :) yup, I said I agree :p the way you put it, it does makes sense...

one thing I forgot to mention before was that the server was set up very securely to avoid repeated brute force attacks ;)

I think I will play around with sessions, you've convinced me that there is a point to them :D

::] krycek [::



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum