SitePoint Sponsor

User Tag List

Results 1 to 12 of 12
  1. #1
    SitePoint Zealot
    Join Date
    Dec 2005
    Location
    New York, NY, U.S.
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Sessions or cookies? Which is more secure?

    Well I basically want to design a fairly secure login system, so I was wondering if sessions or cookies are more secure? and also if PHP is the best method to do this, or maybe PHP in combination with something else like javascript? Thanks.

  2. #2
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well sessions use cookies as well as the more vulnerable URL propogation so face some of the same risks. I think the less you send to the client, the safer you are but cookie data can be encrypted etc. Rule of thumb is not to trust anything that comes from the client. Javascript runs on the client so is inherently insecure.

  3. #3
    SitePoint Zealot
    Join Date
    Dec 2005
    Location
    New York, NY, U.S.
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I thought I read somewhere recently that there was a way to use sessions without cookies? This may be false, but I am almost positive I saw it somewhere. The problem is I don't remember where.

  4. #4
    SitePoint Addict
    Join Date
    Jan 2005
    Location
    United Kingdom
    Posts
    208
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You can use URL propogation which appends the session ID to the URL. But then your exposing your session ID to the world, vulnerable to session fixation.

  5. #5
    SitePoint Zealot
    Join Date
    Dec 2005
    Location
    New York, NY, U.S.
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh, perhaps that was it. Thanks for the quick replies Shrike.

  6. #6
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A common practice is to use session_regenerate_id() and session_destory() to change the session id and remove the data stored under the previous one; this goes a long way towards mitigating session fixation attacks.

  7. #7
    SitePoint Member
    Join Date
    Jun 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The most secure appraoch is not to rely on just one thing (the session ID) whether that be set in a cookie or on the url.

    One approach to this is to generate a random key for a registred session and place that in a cookie or on the url and store it in the session. Then you'd place the session ID in a different place (for example if you place the key in a cookie you'd place the session id on the url). You would then check the key in the cookie matches that in the session and end the session if not.

    To further this you could check the user agent stays consistent throughout the session.

  8. #8
    SitePoint Zealot
    Join Date
    Dec 2005
    Location
    New York, NY, U.S.
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Oh, thanks for the replies. Ceon that sounds like something worth looking into. Any idea on where I could find more information on this to help implement it?

  9. #9
    SitePoint Member
    Join Date
    Jun 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This tutorial outlines checking the user agent amongst other things:
    http://xqus.com/archives/2004/10/19/...-php-sessions/

    This below discusses session security and the stuff I mentioned in the above post. It's in the form of a slide show but is still very useful:
    http://talks.php.net/show/phpworks20...ion-security/1

  10. #10
    SitePoint Zealot
    Join Date
    Dec 2005
    Location
    New York, NY, U.S.
    Posts
    128
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ceon my friend, you have just made my day, and for that I thank you.

  11. #11
    SitePoint Member
    Join Date
    Jan 2006
    Posts
    7
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question Parse error in Sessions example ?

    I was trying to follow the PHP.com sessions tutorial and wanted to try out the code with session_regenerate_id(), but I'm getting an error parsing the code which I'm too new at PHP to understand. Can anyone explain what I'm doing wrong?

    PHP Code:
    session_start();

    if (!isset(
    $_SESSION['initiated']))
    {
        
    session_regenerate_id();
        
    $_SESSION['initiated'] = true;
    }
    /* more code snipped */ 
    From page 10 of the tutorial: http://talks.php.net/show/phpworks20...on-security/10

    The parse error is on the 'initiated' line -- and I really don't get why, since it worked in the isset above. Although... it seems like I'm getting errors in every script I try with the !isset(whatever) syntax.

    Any ideas?
    --Tim
    Last edited by senortim; Jan 26, 2006 at 19:14.

  12. #12
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    359
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by senortim
    PHP Code:
    session_start();

    if (!isset(
    $_SESSION['initiated']))
    {
        
    session_regenerate_id();
        
    $_SESSION['initiated'] = true;
    }
    /* more code snipped */ 
    I'm not sure why you're getting the parse error, but this just made me realize the danger in slides being read in isolation. On this slide, I explained how you can prevent an attack that uses a session identifier that doesn't exist. The problem is that an attacker can still visit your site, obtain a valid session identifier, and then use that in the attack. Read slide 11 for an improved example, or try either of these articles:

    http://shiflett.org/articles/security-corner-feb2004
    http://shiflett.org/articles/the-truth-about-sessions

    Also, session fixation has almost nothing to do with how the session identifier is propagated. I think there is some overlapping discussion in this thread that might cause some confusion.
    Chris Shiflett
    http://shiflett.org/


Bookmarks

Posting Permissions

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