Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Page 1 of 3 123 LastLast
Results 1 to 15 of 31
  1. #1
    Regular Coder
    Join Date
    Nov 2002
    Location
    Bristol, UK
    Posts
    932
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Question Sessions... why bother?

    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?

    ::] krycek [::

    PS - I will be releasing SO_SECURE soon, if anyone wants to help test it please email me: krycek @ soapi . com
    ithium | SOAPI | SDP | PTPScript manual
    "ithium is a non-profit webhost, which is pretty much unique. The mission of ithium is to provide free hosting resources for worthwhile and needy non-profit projects, which otherwise may not be able to obtain such facilities. The money from commercial customers goes to maintain ithium's servers and further development."

  • #2
    Regular Coder
    Join Date
    Oct 2002
    Location
    Milwaukee, Wisconsin
    Posts
    123
    Thanks
    1
    Thanked 0 Times in 0 Posts
    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.

  • #3
    Regular Coder
    Join Date
    Nov 2002
    Location
    Bristol, UK
    Posts
    932
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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 [::
    ithium | SOAPI | SDP | PTPScript manual
    "ithium is a non-profit webhost, which is pretty much unique. The mission of ithium is to provide free hosting resources for worthwhile and needy non-profit projects, which otherwise may not be able to obtain such facilities. The money from commercial customers goes to maintain ithium's servers and further development."

  • #4
    Supreme Overlord Spookster's Avatar
    Join Date
    May 2002
    Location
    Marion, IA USA
    Posts
    6,280
    Thanks
    4
    Thanked 83 Times in 82 Posts
    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.
    Spookster
    CodingForums Supreme Overlord
    All Hail Spookster

  • #5
    Regular Coder
    Join Date
    Nov 2002
    Location
    Bristol, UK
    Posts
    932
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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 [::
    ithium | SOAPI | SDP | PTPScript manual
    "ithium is a non-profit webhost, which is pretty much unique. The mission of ithium is to provide free hosting resources for worthwhile and needy non-profit projects, which otherwise may not be able to obtain such facilities. The money from commercial customers goes to maintain ithium's servers and further development."

  • #6
    Regular Coder
    Join Date
    Nov 2002
    Location
    Bristol, UK
    Posts
    932
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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 it's good to know I haven't got my head the wrong way around about this

    ::] krycek [::
    ithium | SOAPI | SDP | PTPScript manual
    "ithium is a non-profit webhost, which is pretty much unique. The mission of ithium is to provide free hosting resources for worthwhile and needy non-profit projects, which otherwise may not be able to obtain such facilities. The money from commercial customers goes to maintain ithium's servers and further development."

  • #7
    Supreme Overlord Spookster's Avatar
    Join Date
    May 2002
    Location
    Marion, IA USA
    Posts
    6,280
    Thanks
    4
    Thanked 83 Times in 82 Posts
    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 Code:
    <?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.
    Last edited by Spookster; 03-26-2003 at 07:56 PM.
    Spookster
    CodingForums Supreme Overlord
    All Hail Spookster

  • #8
    Regular Coder
    Join Date
    Jun 2002
    Location
    UK
    Posts
    577
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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.
    Ökii - formerly pootergeist
    teckis - take your time and it'll save you time.

  • #9
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,108
    Thanks
    11
    Thanked 101 Times in 99 Posts
    "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 !
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)

  • #10
    Senior Coder missing-score's Avatar
    Join Date
    Jan 2003
    Location
    UK
    Posts
    2,194
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Will that example last?

    That example that spookster gave, will it remain a variable on future pages, so like:

    PHP Code:
    <?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?

  • #11
    New Coder
    Join Date
    Aug 2002
    Posts
    76
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Yes it does as long as you use session_start() first.

  • #12
    Senior Coder
    Join Date
    Jun 2002
    Location
    near Oswestry
    Posts
    4,508
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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?
    "Why bother with accessibility? ... Because deep down you know that the web is attractive to people who aren't exactly like you." - Joe Clark

  • #13
    Regular Coder
    Join Date
    Nov 2002
    Location
    Bristol, UK
    Posts
    932
    Thanks
    0
    Thanked 0 Times in 0 Posts
    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...

    ::] krycek [::
    ithium | SOAPI | SDP | PTPScript manual
    "ithium is a non-profit webhost, which is pretty much unique. The mission of ithium is to provide free hosting resources for worthwhile and needy non-profit projects, which otherwise may not be able to obtain such facilities. The money from commercial customers goes to maintain ithium's servers and further development."

  • #14
    Super Moderator
    Join Date
    May 2002
    Location
    Perth Australia
    Posts
    4,108
    Thanks
    11
    Thanked 101 Times in 99 Posts
    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!
    resistance is...

    MVC is the current buzz in web application architectures. It comes from event-driven desktop application design and doesn't fit into web application design very well. But luckily nobody really knows what MVC means, so we can call our presentation layer separation mechanism MVC and move on. (Rasmus Lerdorf)

  • #15
    Senior Coder missing-score's Avatar
    Join Date
    Jan 2003
    Location
    UK
    Posts
    2,194
    Thanks
    0
    Thanked 0 Times in 0 Posts

    I agree

    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.


  •  
    Page 1 of 3 123 LastLast

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •