SitePoint Sponsor

User Tag List

Results 1 to 25 of 25
  1. #1
    SitePoint Zealot rawkes's Avatar
    Join Date
    Oct 2006
    Location
    Surrey, UK
    Posts
    121
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Storing passwords in sessions, why?

    What is the reasoning behind storing the users password in a session / cookie? Where else would it be used apart from authenticating the user the very first time they log in (before the session is even created)?
    Rawkes - Standards based web design and development

  2. #2
    SitePoint Zealot glowdot's Avatar
    Join Date
    Jun 2007
    Location
    Santa Monica, CA
    Posts
    111
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    How else would you know that they have actually logged in, and not just bypassed the login page to get to the privileged page?
    Advertise on Glowfoto
    banners as low as $25/month, text ads $10/month
    Share 10 million impressions per month!

  3. #3
    SitePoint Zealot rawkes's Avatar
    Join Date
    Oct 2006
    Location
    Surrey, UK
    Posts
    121
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Because a session would exist with their userID, surely? I just don't understand the use of the password after they have used it to log in.
    Rawkes - Standards based web design and development

  4. #4
    SitePoint Zealot glowdot's Avatar
    Join Date
    Jun 2007
    Location
    Santa Monica, CA
    Posts
    111
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ah, I think I misunderstood your question.

    If you don't need the password later, then you don't need to store it. As for storing it in a cookie though, this is sometimes used to allow sessions to be authenticated across subdomains (although there are other, better ways).
    Advertise on Glowfoto
    banners as low as $25/month, text ads $10/month
    Share 10 million impressions per month!

  5. #5
    ✯✯✯ silver trophybronze trophy php_daemon's Avatar
    Join Date
    Mar 2006
    Posts
    5,284
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Bad practice in any case.
    Saul

  6. #6
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,807
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    Never store sensitive information in a session/cookie or otherwise. there is absolutley NO need to store anything sensitive other than perhaps an id number so you can query the database.
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  7. #7
    SitePoint Zealot rawkes's Avatar
    Join Date
    Oct 2006
    Location
    Surrey, UK
    Posts
    121
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is exactly what I thought, but time and time again I see threads here with people storing the username and password in the session/cookie and wanted to know if there was any reason for their madness.
    Rawkes - Standards based web design and development

  8. #8
    ✯✯✯ silver trophybronze trophy php_daemon's Avatar
    Join Date
    Mar 2006
    Posts
    5,284
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Yep, be very careful of what you're picking up on the net. You can get lots of ideas and learn a lot but you can pick up bad practices just as easy.
    Saul

  9. #9
    SitePoint Zealot rawkes's Avatar
    Join Date
    Oct 2006
    Location
    Surrey, UK
    Posts
    121
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I was having another think about this. I understand storing a password in the session is pointless, but say the user ticked "Remember me for 2 weeks" when they log in - wouldn't I need to store the password in the cookie so they get logged in automatically in say 3 days time? It's just if I only stored the userID in the cookie, then they could easily change that and log themselfs in as someone else without entering a password.
    Rawkes - Standards based web design and development

  10. #10
    SitePoint Wizard frank1's Avatar
    Join Date
    Oct 2005
    Posts
    1,392
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    well
    when people start coding in php ..most book ..tutorials found in the net...shows using session rather than storing in database


    so people are not able to give that habit for long term....
    so

  11. #11
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database). Then use the SQL:
    Code sql:
    SELECT *
    FROM users
    WHERE user_id = {$_SESSION['user_id']}
    AND hash = {$_SESSION['hash']}
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  12. #12
    SitePoint Zealot rawkes's Avatar
    Join Date
    Oct 2006
    Location
    Surrey, UK
    Posts
    121
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlienDev View Post
    All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database). Then use the SQL:
    Code sql:
    SELECT *
    FROM users
    WHERE user_id = {$_SESSION['user_id']}
    AND hash = {$_SESSION['hash']}
    That makes sense, It could be made even more secure by changing the HASH stored in the db/session/cookie every so often. Thanks for the tip.
    Rawkes - Standards based web design and development

  13. #13
    SitePoint Zealot rawkes's Avatar
    Join Date
    Oct 2006
    Location
    Surrey, UK
    Posts
    121
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlienDev View Post
    All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database).
    That makes sense, It could be made even more secure by changing the HASH stored in the db/session/cookie every so often. Thanks for the tip.
    Rawkes - Standards based web design and development

  14. #14
    SitePoint Member Lysyi's Avatar
    Join Date
    Oct 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Storing passwords in cookie - definitely NOT!
    Just because it could be easily stolen because they're sent unencrypted over the web.

    But storing passwords in session may make sense.
    Session vars are not passed through http and so could not be stolen.
    For example, for integrating two scripts together.
    I recently integrated a flashchat script into phpfox.
    When a user logs into phpfox his username/password are stored into session.
    And if then he decides to visit the chat, a scripts performs automatic authentication, taking username/password from session, so the user doesn't need to login again.
    Now I'm integrating a webmail script into the same instance of phpfox using the same scheme.
    So in the case of integrating several scripts together storing passwords in session (but NOT in cookies) may make a lot of sense and be very useful

  15. #15
    dooby dooby doo silver trophybronze trophy
    spikeZ's Avatar
    Join Date
    Aug 2004
    Location
    Manchester UK
    Posts
    13,807
    Mentioned
    158 Post(s)
    Tagged
    3 Thread(s)
    Mike Swiffin - Community Team Advisor
    Only a woman can read between the lines of a one word answer.....

  16. #16
    SitePoint Member Lysyi's Avatar
    Join Date
    Oct 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by spikeZ View Post
    Guy's, have you not heard of SESSION HIJACKING?
    okay, when session is hijacked, all you can steal is just the sessionID.
    so you can have access to the user's member zone for a limited time until he logs out.
    but you don't have access to session variables
    for this you must have access to the server's hard disk
    so the password still remains secure

  17. #17
    SitePoint Evangelist -T-'s Avatar
    Join Date
    Jun 2002
    Posts
    444
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    My rules of thumb
    1. store as little information about the user
    in cookies, userid (and maybe hashed + salted version of the password if it's a remember me cookie, so the user can't just change the cookie to get access to others accounts. Though, make sure you use a different salt then you use in the database, or even better, make a hash of the hashed password stored in the database with a new salt)

    2. keeping information about the user in sessions is somewhat safe, but you have to make sure you do not print out the contents of the session to the user anywhere, and make sure that they are not stored in the default dir (/tmp in nix boxes). If they are stored in the default dir they can be read by other people on the server (only true on shared hosts, but still a nice rule to keep in hand at all times)


    Spikez, even though a session is hijacked the information stored in it can not be read unless the script itself reads and print it out to the user. A session hijacking does not give the hijacker access to more information about the user then the user can see in the on the page himself. And if he has the session, he can go into the usercp (or whatever you want to call it) and get information on the user. It really doesn't matter if it's stored in the database or the session, the information is there.

    I'm not saying it's impossible to get information out of a session, but it's not the direct fault of a hijacking.
    chrome is a wrapper that combines a browser with spyware

  18. #18
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    FYI, the default configuration for PHP is to store sessions as world-readable/writable files in a temporary directory. This means that even in shared hosting situations that are "secure" because they use su_exec (or similar), your sessions are still there to be read by anybody on the server. This includes anyone who manages to gain control of another users' badly-coded app. When you know this, I can't imagine any reason why you would ever store anything sensitive in a session even if it isn't sent across the web.

    For Lysyi's situation where s/he needed to integrate several scripts together, I would use a temporary table to store the user's password and not store them in a session variable. Although honestly I'd spend more time hacking to make sure I didn't need to even do that (I've written complicated login scripts that effectively log a user into multiple different apps at the same time, thus completely negating the need to store the user's password in plaintext anywhere while still seamlessly integrating disparate session schemes).
    PHP questions? RTFM
    MySQL questions? RTFM

  19. #19
    SitePoint Member Lysyi's Avatar
    Join Date
    Oct 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Kromey,
    but it's quite secure for dedicated servers?
    and what about co-location?

    could you let me take a look at your complicated login scripts' code?
    are any of them open source?

    regards,
    Ilya

  20. #20
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ilya,
    Sadly I'm not at liberty to share my complicated login scripts - they were written for the company I worked for at the time and thus belong to them. However, since the concept behind them is not patented (nor can it be, seeing as there is prior art and it is an obvious idea), I will share the way I created them:

    Each app has its own login code. This code needs only the user's username and password (rarely are there any exceptions to this), and it takes care of everything that needs doing to log the user into the app (setting up the session or setting its own cookie or whatever). Thus the general approach is to wrap each app's login code in its own function which is then called in sequence from your site's login script, and voila! your users are logged in to every app on your site!

    The only time this gets tricky is when multiple apps use identical $_SESSION variables. I solve this by doing find&replace in each app, replacing "$_SESSION['" with "$_SESSION['$app_", where $app is a unique prefix for that application (e.g. a prefix for phpBB might be "pbb", turning $_SESSION['user'] into $_SESSION['pbb_user']). Another option here would be two-dimensional $_SESSION array, e.g. $_SESSION['pbb']['user'], which may help debugging if you need to dump the $_SESSION array.

    Another sticky spot I ran into once was two separate apps that took care of their own session handling by setting cookies; the problem was both apps named their cookies "login". Of course, since both were written such that the only code that directly accessed these cookies was the login code that I copied into my uber-login script and a single include that was called at the top of every file, changing the name of the cookies was easy (I used the same app-specific prefix that I used for $_SESSION variables for these cookies, so they became "app1_login" and "app2_login").

    Yes, it takes some work to pull off, but it's more secure than storing passwords in plaintext where anyone can read them.

    However, you are right, Ilya, when you point out that on dedicated servers, virtual dedicated servers, and co-located servers, world-readable session files are not a significant risk; most people, however, are in shared hosting situations and thus need to be aware of the significant risk they put their users in when they store passwords in such an insecure manner.
    PHP questions? RTFM
    MySQL questions? RTFM

  21. #21
    SitePoint Member Lysyi's Avatar
    Join Date
    Oct 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, Kromey, a very interesting approach. Maybe I will use it in my future work. Thank you for the idea.

    But I think I have an idea how to make sessions very, very secure even on a shared hosting.
    Let's just encrypt the variables with Mcrypt!
    It supports many powerful algorythms, for example AES which is adopted as an encryption standard by the U.S. government.
    The key can be stored in a non-world-readable file on server, or in the database.
    We just encrypt all variables with mcrypt, and then just decrypt them when needed. The process is very fast and won't eat up a lot of resources.
    I think in many cases it could be a more faster solution than storing data in mysql. Or I'm wrong?
    And even if someone reads session files on a shared hosting, s/he won't get any data, just a cipher without the key.

    But still the problem of cookie or session id hijacking remains.
    To solve this problem needed something like "unsent cookie".
    That is a cookie which is stored in client's browser only and isn't sent over the web.
    This also could be a text file on user's hard disk. The file stores the password.
    With every http request server sends a challenge string in a cookie. The browser combines it with the stored password using HMAC and in the next request to the server sends the md5 (or sha1) of this. The server performs analogous operation itself and compares results. This is called CHAP (Challenge-handshake authentication protocol).
    So authentication is made at every request, and even if a cookie is hijacked, the hijacker won't get into the member zone without knowing the password.
    But how to implement this?
    There is no support for "unsent cookies" in browsers. Javascript cannot access files on clients computer (or can?). Maybe this can be done with Java?
    What do you think?

  22. #22
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's very similar to how NTLM or Kerberos work. Unfortunately, seamless integration in a browser- and platform-agnostic is unbelievably difficult. Getting Kerberos working is easier than NTLM (unless you're a Windows-only shop), but it's still no trivial task, and there still seem to be plenty of browsers who do not support Kerberos (IE and FF do, however I believe (but have not tested) that Safari, Opera, Konquerer do not). Add to the fact that Kerberos is designed for LAN setups and not the internet, and you have a complex problem.

    I once dreamed up a scheme where every response from the server included a one-time-use token (stored in a cookie); the next request must include this token or be rejected. This makes session hijacking more difficult (you not only need a valid session ID, you need the appropriate token as well), but is still far from fool-proof.

    Another idea I had was a lot more complex and completely destroys accessibility because it requires the user have a modern browser with JavaScript enabled: every page request is in fact an AJAX request. The user in actuality never leaves index.php, and instead is sending requests via AJAX. This enables a JavaScript-based CHAP scheme similar to what you described possible (because no, JavaScript cannot access local files, nor is there anything like an "unsent cookie"). The downsides are a site on which your users cannot bookmark particular pages (since they're always on index.php, they always bookmark index.php), it completely fails when JavaScript is disabled or otherwise unavailable (thus completely destroying accessibility), and users who watch the location bar may be confused by the fact that they never appear to move.

    I suppose it may be possible to achieve a similar effect by using JavaScript to set a cookie for your domain (you can't set cookies for other domains anyway) but for a non-existent path, thus creating a cookie that is in effect never sent. I'm going to run some tests and see if this is possible...

    Edit:


    Yes, you can set cookies for non-existent paths. Unfortunately, cookies are only available to the page if they would be sent to the server on this request. Thus setting a cookie for a non-existent path is useless because you can never access it.
    Last edited by kromey; Jun 26, 2007 at 10:44. Reason: update
    PHP questions? RTFM
    MySQL questions? RTFM

  23. #23
    SitePoint Member Lysyi's Avatar
    Join Date
    Oct 2005
    Posts
    15
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Your idea with AJAX is great!
    I beleive there are only some 5% users who turn off javascript in their browsers.

    I think integration of "unsent cookie" into browsers is much easier than Kerberos or NTLM.
    Maybe it's worth of becoming a standart for all browsers?
    And what about not Javascript, but Java. Do you know if it can create and access files on user's hard disk?

  24. #24
    Worship the Krome kromey's Avatar
    Join Date
    Sep 2006
    Location
    Fairbanks, AK
    Posts
    1,621
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've never used Java (aside from a school project once where I had to put a ready-made Java applet on my website) and am completely unaware of its abilities in this regard.

    If you don't mind locking out your users who don't have JavaScript, then by all means use my AJAX idea. Most of my sites need to be accessible (i.e. people who need to use screen readers need to be able to use it just as well as Eagle-Eye Joe with his 20/10 vision), so it's not something I can use. My sites use JavaScript to enhance the experience, but I take great care to ensure that the entire site can be used effectively without JavaScript (and for that matter, without even CSS).
    PHP questions? RTFM
    MySQL questions? RTFM

  25. #25
    SitePoint Enthusiast
    Join Date
    Jun 2003
    Location
    Spain
    Posts
    65
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlienDev View Post
    All you ever need to store in a session is the user id and a string on random characters (created when user registers and stored in database). Then use the SQL:
    Code sql:
    SELECT *
    FROM users
    WHERE user_id = {$_SESSION['user_id']}
    AND hash = {$_SESSION['hash']}
    This is how i currently do this, are there any downsides to this method?

    Would anything extra be overkill?


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
  •