The forums have permanently moved to This forum will be kept around in read-only mode for archival purposes. To learn how to continue using your existing account on the new forums, check out this thread.

Results 1 to 7 of 7

Thread: Secure "remember me" login

  1. #1

    Secure "remember me" login

    I've been reading quite a few tutorials on "remember me" login implementation. Many of them store the username and a double hashed password in a cookie. This is so that hackers will neither know the plain text nor the database once-hashed password:

    PHP Code:
    setcookie('pass'md5(sha1($password 'salt1') . 'salt2'), REMEMBER_TIME); 
    Then to auto log the user back in you do a check with the database:

    PHP Code:
    if (isset($_COOKIE['pass'] &&
    $_COOKIE['pass'] == md5($databasePassword 'salt2')) {

    My question is how secure this method is from a hacker simply copy and pasting the cookie file. They don't know the user's original plain text password, but the hacker can hijack the account forever.

    Someone suggested to me that I also need to store the IP of the user in the database. This way, I can guarantee that the hijacker must be using the same computer. This would cut out a ton of hack scenarios because you generally trust the people you share your computer with.

    PHP Code:
    if ($allTheAboveChecks && 
    $_SERVER['REMOTE_ADDR'] == $ipInDatabase) {

    What are your thoughts?

  2. #2
    There is a method that was written by Chris Shiflett 5yrs ago:

    Which is still a great article and method of storing a session, which you could just as easily translate into a "cookie". It might be able to provide you w/ some information or some insight on another method of sessions/cookie storing.

    However, w/ all that being said, storing a cookie normally should suffice. If security is THAT huge of an issue for your application, then you shouldn't have the remember me option at all anyway. Seems to me as if you're looking way to much into this. And storing IP wouldn't really work, cause lots of ppl have dynamic IP addresses.
    Let us live so that when we come to die even the undertaker will be sorry. - Mark Twain
    Don't PM me your CSS, xHTML, JS or PHP questions. I will not reply to ANY IE6 questions.

  3. #3
    You would have to store the IP address each and every time they actually log in.

    Twitter / The Human Conditions

    biznuge: "that doesn't grammatical sense..."

  4. #4
    1. Is it true that normal sessions are stored in RAM and database (harddrive) stored sessions would be thousands of times slower to access?

    2. How often do IP addresses change on average?

  5. #5
    Quote Originally Posted by NeoDreamer View Post
    1. Is it true that normal sessions are stored in RAM and database (harddrive) stored sessions would be thousands of times slower to access?

    2. How often do IP addresses change on average?
    1. Some nerd from another forum said sessions are stored in files on the disk, so they are approximately the same access time as a database read.

    2. Another nerd said not all people's IP's change, but for those who do, it changes around every 2 weeks.

  6. #6
    What you're describing is called session hijacking through cookie stealing, and it's one of the primary reasons why XSS injection holes are so dangerous. By default, cookies are accessible from JavaScript, enabling XSS-injected scripts to read the user's cookies and send them to an attacker.

    As there is no reliable way to track an individual user over HTTP, it is useless to try and prevent the fact that physically copying a user's cookie will grant access to the same session. What you can and should do, however, is to prevent this from happening remotely, ie. without physical access to the client's machine.

    First and foremost, you must make sure to not create any XSS holes! It's dangerously easy to create XSS injection holes, even more so in PHP. The golden rule in security is to never trust user input. In PHP, by far the most common way XSS holes are created is by directly writing user input back to the HTML output. Consider the scenario of a simple guestbook; 2 form fields that are simply written to and read from a database and printed directly on the page. As soon as the user input contains any HTML code or JavaScript, you've effectively enabled them to inject their code on your pages, including scripts that steal user cookies allowing attackers to hijack their sessions.

    Your basic tool to prevent this is the htmlentities or htmlspecialchars function, which will HTML-encode characters like <, >, " etc preventing user input from being interpreted as actual HTML code by the client's browser. When using these functions, make sure to specify the correct charset! There have been known cases of vulnerabilities caused by the effect of these functions getting bypassed due to specifying the wrong charset, most notably Google's UTF-7 vulnerability.

    To further mitigate this problem, Microsoft created an HttpOnly cookie flag which is respected by most recent browsers. If this flag is activated, the browser will know not to make the cookie available to JavaScript, preventing malicious scripts injected through any XSS holes from stealing user cookies. They're implemented in PHP since version 5.2.0, and I recommend you use them unless you have a good reason not to.

    Note that there are more ways to perform session hijacking than just cookie stealing. For example, another common attack is session fixation, where the attacker attempts to set a user's session ID to one he has access to. For example, the attacker could create a session on the server and then trick the user into using the same session (eg. by having him visit a URL with the session ID in it). Once the user has logged in, the attacker will effectively be logged in as that user since he's using the same session.

    To prevent session fixation, it is recommended to create new sessions on each privilege-escalating action (logging in obviously being the most important one). If you're under a session ID fixed by an attacker but the server assigns you a new session when logging in, your new session will get you logged in but the attacker will still be using the old, non-logged-in session.

    Additionally, you should make sure to tell PHP to never accept session IDs from URLs, and instead accept them only from session cookies. This is done using the session.use_trans_id and session.use_only_cookies INI directives, respectively. By default they're set to the right values, but you should make sure either way.

    Furthermore, there is the issue of securing your session information on the server. By default, PHP stores sessions in the /tmp directory. If you're on a shared host, this poses a few security concerns. If for every account on the shared server the webserver runs under the same UNIX user, then it is possible for one user to read or overwrite another user's session data. Granted, there is PHP's safe_mode to prevent this, but this protection is virtually useless since it's not always activated and any other language can be used anyway (as long as it runs under the same webserver user, eg. cgi scripts). A better solution would be to store your sessions in a database, as simplistik pointed out above.

    Of course, all these countermeasures are still null and void if you're sending your cookies over unencrypted HTTP, as they can easily be sniffed along the way.

    Obviously there are far more potential security risks than just these, but I'll leave those as an exercise to the reader

    To further answer your questions:

    Quote Originally Posted by NeoDreamer View Post

    Is it true that normal sessions are stored in RAM and database (harddrive) stored sessions would be thousands of times slower to access?

    2. How often do IP addresses change on average?
    1. There is no such thing as a "normal" session. PHP's default is the /tmp directory, but you can just as easily write session handlers to save them in RAM or on a DB (and in some cases you should for reasons explained above). It is true that initially accessing sessions on a HD is slower, but chances are that your server OS is just going to keep them in memory for subsequent requests. Similarly, databases are pretty good at minimizing disk access times and are likely to keep stuff in memory for quick access.

    2. You really don't want to get into IP tracking. It's simply unreliable and no matter how clever the method you come up with, it's always going to break for some part of your (potential) visitors.
    Wait, what?

  7. #7
    jwilliam's Avatar
    An intellectual carrot!
    Voetsjoeba, I believe you just squeezed the entire contents of O'Reilly's "Essential PHP Security" into a single forum post. Bravo

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

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

Home About Meet the Moderators Advertise

 Link to Us


Copyright 1999 - 2012