Keep Me Logged In - the best approach

Question

My web application uses sessions to store information about the user once they ve logged in  and to maintain that information as they travel from page to page within the app  In this specific application  I m storing the user id  first name and last name of the person    I d like to offer a  Keep Me Logged In  option on log in that will put a cookie on the user s machine for two weeks  that will restart their session with the same details when they return to the app   What is the best approach for doing this  I don t want to store their user id in the cookie  as it seems like that would make it easy for one user to try and forge the identity of another user

User · Answer

Generate a hash  maybe with a secret only you know  then store it in your DB so it can be associated with the user  Should work quite well

User · Answer

I asked one angle of this question here  and the answers will lead you to all the token-based timing-out cookie links you need   Basically  you do not store the userId in the cookie  You store a one-time token  huge string  which the user uses to pick-up their old login session  Then to make it really secure  you ask for a password for heavy operations  like changing the password itself

User · Answer

I read all the answers and still found it difficult to extract what I was supposed to do  If a picture is worth 1k words I hope this helps others implement a secure persistent storage based on Barry Jaspan s Improved Persistent Login Cookie Best Practice    If you have questions  feedback  or suggestions  I will try to update the diagram to reflect for the newbie trying to implement a secure persistent login

User · Answer

Security Notice  Basing the cookie off an MD5 hash of deterministic data is a bad idea  it s better to use a random token derived from a CSPRNG  See ircmaxell s answer to this question for a more secure approach    Usually I do something like this    User logs in with  keep me logged in    Create session   Create a cookie called SOMETHING containing  md5 salt username ip salt  and a cookie called somethingElse containing id    Store cookie in database   User does stuff and leaves ----   User returns  check for somethingElse cookie  if it exists  get the old hash from the database for that user  check of the contents of cookie SOMETHING match with the hash from the database  which should also match with a newly calculated hash  for the ip  thus  cookieHash  databaseHash  md5 salt username ip salt   if they do  goto 2  if they don t goto 1   Off course you can use different cookie names etc  also you can change the content of the cookie a bit  just make sure it isn t to easily created  You can for example also create a user salt when the user is created and also put that in the cookie    Also you could use sha1 instead of md5  or pretty much any algorithm

User · Answer

OK  let me put this bluntly  if you re putting user data  or anything derived from user data into a cookie for this purpose  you re doing something wrong    There  I said it  Now we can move on to the actual answer   What s wrong with hashing user data  you ask  Well  it comes down to exposure surface and security through obscurity    Imagine for a second that you re an attacker  You see a cryptographic cookie set for the remember-me on your session  It s 32 characters wide  Gee  That may be an MD5     Let s also imagine for a second that they know the algorithm that you used  For example   md5 salt username ip salt    Now  all an attacker needs to do is brute force the  salt   which isn t really a salt  but more on that later   and he can now generate all the fake tokens he wants with any username for his IP address  But brute-forcing a salt is hard  right  Absolutely  But modern day GPUs are exceedingly good at it  And unless you use sufficient randomness in it  make it large enough   it s going to fall quickly  and with it the keys to your castle   In short  the only thing protecting you is the salt  which isn t really protecting you as much as you think   But Wait   All of that was predicated that the attacker knows the algorithm  If it s secret and confusing  then you re safe  right  WRONG  That line of thinking has a name  Security Through Obscurity  which should NEVER be relied upon   The Better Way  The better way is to never let a user s information leave the server  except for the id    When the user logs in  generate a large  128 to 256 bit  random token  Add that to a database table which maps the token to the userid  and then send it to the client in the cookie   What if the attacker guesses the random token of another user    Well  let s do some math here  We re generating a 128 bit random token  That means that there are   possibilities   2 128 possibilities   3 4   10 38   Now  to show how absurdly large that number is  let s imagine every server on the internet  let s say 50 000 000 today  trying to brute-force that number at a rate of 1 000 000 000 per second each  In reality your servers would melt under such load  but let s play this out   guesses per second   servers   guesses guesses per second   50 000 000   1 000 000 000 guesses per second   50 000 000 000 000 000   So 50 quadrillion guesses per second  That s fast  Right   time to guess   possibilities   guesses per second time to guess   3 4e38   50 000 000 000 000 000 time to guess   6 800 000 000 000 000 000 000   So 6 8 sextillion seconds      Let s try to bring that down to more friendly numbers   215 626 585 489 599 years   Or even better   47917 times the age of the universe   Yes  that s 47917 times the age of the universe      Basically  it s not going to be cracked   So to sum up   The better approach that I recommend is to store the cookie with three parts    function onLogin  user         token   GenerateRandomToken       generate a token  should be 128 - 256 bit     storeTokenForUser  user   token        cookie    user          token       mac   hash hmac  sha256    cookie  SECRET KEY        cookie           mac      setcookie  rememberme    cookie       Then  to validate   function rememberMe          cookie   isset   COOKIE  rememberme        COOKIE  rememberme             if   cookie            list   user   token   mac    explode       cookie           if   hash equals hash hmac  sha256    user          token  SECRET KEY    mac                 return false                     usertoken   fetchTokenByUserName  user           if  hash equals  usertoken   token                 logUserIn  user                       Note  Do not use the token or combination of user and token to lookup a record in your database  Always be sure to fetch a record based on the user and use a timing-safe comparison function to compare the fetched token afterwards  More about timing attacks   Now  it s very important that the SECRET KEY be a cryptographic secret  generated by something like  dev urandom and or derived from a high-entropy input   Also  GenerateRandomToken   needs to be a strong random source  mt rand   is not nearly strong enough  Use a library  such as RandomLib or random compat  or mcrypt create iv   with DEV URANDOM      The hash equals   is to prevent timing attacks  If you use a PHP version below PHP 5 6 the function hash equals   is not supported  In this case you can replace hash equals   with the timingSafeCompare function          A timing safe equals comparison       To prevent leaking length information  it is important    that user input is always used as the second parameter         param string  safe The internal  safe  value to be checked     param string  user The user submitted  unsafe  value        return boolean True if the two strings are identical      function timingSafeCompare  safe   user        if  function exists  hash equals              return hash equals  safe   user      PHP 5 6              Prevent issues if string length is 0      safe    chr 0        user    chr 0           mbstring func overload can make strlen   return invalid numbers        when operating on raw binary strings  force an 8bit charset here      if  function exists  mb strlen               safeLen   mb strlen  safe   8bit             userLen   mb strlen  user   8bit          else            safeLen   strlen  safe            userLen   strlen  user                 Set the result to the difference between the lengths      result    safeLen -  userLen          Note that we ALWAYS iterate over the user-supplied length        This is to prevent leaking length information     for   i   0   i  lt   userLen   i                 Using   here is a trick to prevent notices            It s safe  since if the lengths are different             result is already non-0          result     ord  safe  i    safeLen     ord  user  i                   They are only identical strings if  result is exactly 0        return  result     0

User · Answer

I think you could just do this   cookieString   password hash  username  PASSWORD DEFAULT    Store  cookiestring in the DB and and set it as a cookie  Also set the username of the person as a cookie  The whole point of a hash is that it can t be reverse-engineered  When a user turns up  get the username from one cookie  than  cookieString from another  If  cookieString matches the one stored in the DB  then the user is authenticated  As password hash uses a different salt each time  it is irrelevant as to what the clear text is

User · Answer

I would recommend the approach mentioned by Stefan  i e  follow the guidelines in Improved Persistent Login Cookie Best Practice  and also recommend that you make sure your cookies are HttpOnly cookies so they are not accessible to  potentially malicious  JavaScript

User · Answer

Introduction  Your title    Keep Me Logged In    - the best approach make it difficult for me to know where to start because if you are looking at best approach then you would have to consideration the following     Identification Security    Cookies  Cookies are vulnerable  Between common browser cookie-theft vulnerabilities and cross-site scripting attacks we must accept that cookies are not safe  To help improve security you must note that php setcookies has additional functionality such as      bool setcookie   string  name    string  value    int  expire   0    string  path    string  domain    bool  secure   false    bool  httponly   false             secure  Using HTTPS connection  httponly  Reduce identity theft through XSS attack    Definitions    Token   Unpredictable random string of n length eg   dev urandom  Reference   Unpredictable random string of n length eg   dev urandom  Signature  Generate a keyed hash value using the HMAC method    Simple Approach   A simple solution would be     User is logged on with Remember Me Login Cookie issued with token  amp  Signature When is returning  Signature is checked If Signature is ok    then username  amp  token is looked up in the database  if not valid    return to login page If valid automatically login    The above case study summarizes all example given on this page but they disadvantages is that    There is no way to know if the cookies was stolen Attacker may be access  sensitive operations such as change of password or data such as personal and baking information etc  The compromised cookie would still be valid for the cookie life span    Better Solution  A better solution would be    User is logged in and remember me is selected  Generate Token  amp  signature and store in cookie  The tokens are random and are only valid for single autentication  The token are replace on each visit to the site When a non-logged user visit the site  the signature  token and username are verified  Remember me login should have limited access and not allow modification of password  personal information etc    Example Code      Set privateKey    This should be saved securely   key    fc4d57ed55a78de1a7b31e711866ef5a2848442349f52cd470008f6d30d47282    key   pack  H     key      They key is used in binary form     Am Using Memecahe as Sample Database  db   new Memcache     db- gt addserver  127 0 0 1     try          Start Remember Me      rememberMe   new RememberMe  key        rememberMe- gt setDB  db      set example database         Check if remember me is present     if   data    rememberMe- gt auth              printf  Returning User  s n    data  user                 Limit Acces Level            Disable Change of password and private information etc        else              Sample user          user    baba               Do normal login          rememberMe- gt remember  user           printf  New Account  s n    user           catch  Exception  e        printf   Error   s n    e- gt getMessage         Class Used   class RememberMe       private  key   null      private  db       function   construct  privatekey             this- gt key    privatekey             public function setDB  db             this- gt db    db             public function auth                 Check if remeber me cookie is present         if    isset   COOKIE  auto       empty   COOKIE  auto                   return false                        Decode cookie value         if     cookie    json decode   COOKIE  auto    true                 return false                        Check all parameters         if     isset  cookie  user       isset  cookie  token       isset  cookie  signature                    return false                      var    cookie  user      cookie  token                Check Signature         if     this- gt verify  var   cookie  signature                   throw new Exception  Cokies has been tampared with                          Check Database          info    this- gt db- gt get  cookie  user             if     info                return false     User must have deleted accout                       Check User Data         if     info   json decode  info  true                 throw new Exception  User Data corrupted                          Verify Token         if   info  token        cookie  token                  throw new Exception  System Hijacked or User use another browser                                      Important            To make sure the cookie is always change            reset the Token information                       this- gt remember  info  user             return  info             public function remember  user             cookie                      user    gt   user                   token    gt   this- gt getRand 64                    signature    gt  null                     cookie  signature      this- gt hash  cookie  user      cookie  token              encoded   json encode  cookie               Add User to database          this- gt db- gt set  user   encoded                           Set Cookies            In production enviroment Use            setcookie  auto    encoded  time      expiration     root                example com   1  1                       setcookie  auto    encoded      Sample            public function verify  data   hash             rand   substr  hash  0  4           return  this- gt hash  data   rand       hash             private function hash  value   rand   null             rand    rand     null    this- gt getRand 4     rand          return  rand   bin2hex hash hmac  sha256    value    rand   this- gt key  true               private function getRand  length            switch  true                case function exists  mcrypt create iv                      r   mcrypt create iv  length  MCRYPT DEV URANDOM                   break              case function exists  openssl random pseudo bytes                      r   openssl random pseudo bytes  length                   break              case is readable   dev urandom        deceze                  r   file get contents   dev urandom   false  null  0   length                   break              default                    i   0                   r                       while  i     lt   length                         r    chr mt rand 0  255                                      break                    return substr bin2hex  r   0   length             Testing in Firefox  amp  Chrome     Advantage    Better Security  Limited access for attacker  When cookie is stolen its only valid for single access  When next the original user access the site you can automatically detect and notify the user of theft    Disadvantage    Does not support persistent connection via multiple browser  Mobile  amp  Web  The cookie can still be stolen because the user only gets the notification after the next login    Quick Fix   Introduction of approval system for each system that must have persistent connection  Use multiple cookies for the authentication   Multiple Cookie Approach  When an attacker is about to steal cookies the only focus it on a particular website or domain eg  example com  But really you can authenticate a user from 2 different domains  example com  amp  fakeaddsite com  and make it look like  Advert Cookie     User Logged on to example com with remember me Store username  token  reference in cookie Store username  token  reference in Database eg  Memcache  Send refrence id via get and iframe to fakeaddsite com fakeaddsite com uses the reference to fetch user  amp  token from Database fakeaddsite com stores the signature When a user is returning fetch signature information with iframe from fakeaddsite com Combine it data and do the validation        you know the remaining   Some people might wonder how can you use 2 different cookies   Well its possible  imagine example com   localhost and fakeaddsite com   192 168 1 120  If you inspect the cookies it would look like this     From the image above    The current site visited is localhost  It also contains cookies set from 192 168 1 120   192 168 1 120   Only accepts defined HTTP REFERER Only accepts connection from specified REMOTE ADDR No JavaScript  No content but consist nothing rather than sign information and add or retrieve it from cookie    Advantage   99  percent of the time you have tricked the attacker  You can easily lock the account in the attacker first attempt   Attack can be prevented even before the next login like the other methods    Disadvantage    Multiple Request to server just for a single login    Improvement    Done use iframe use ajax

User · Answer

Old thread  but still a valid concern  I noticed some good responses about security  and avoiding use of  security through obscurity   but the actual technical methods given were not sufficient in my eyes  Things I must say before I contribute my method    NEVER store a password in clear text   EVER  NEVER store a user s hashed password in more than one location in your database  Your server backend is always capable of pulling the hashed password from the users table  It s not more efficient to store redundant data in lieu of additional DB transactions  the inverse is true  Your Session ID s should be unique  so no two users could ever share an ID  hence the purpose of an ID  could your Driver s License ID number ever match another persons  No   This generates a two-piece unique combination  based on 2 unique strings  Your Sessions table should use the ID as the PK  To allow multiple devices to be trusted for auto-signin  use another table for trusted devices which contains the list of all validated devices  see my example below   and is mapped using the username  It serves no purpose to hash known data into a cookie  the cookie can be copied  What we are looking for is a complying user device to provide authentic information that cannot be obtained without an attacker compromising the user s machine  again  see my example   This would mean  however  that a legitimate user who forbids his machine s static information  i e  MAC address  device hostname  useragent if restricted by browser  etc   from remaining consistent  or spoofs it in the first place  will not be able to use this feature  But if this is a concern  consider the fact that you are offering auto-signin to users whom identify themselves uniquely  so if they refuse to be known by spoofing their MAC  spoofing their useragent  spoofing changing their hostname  hiding behind proxies  etc   then they are not identifiable  and should never be authenticated for an automatic service  If you want this  you need to look into smart-card access bundled with client-side software that establishes identity for the device being used    That all being said  there are two great ways to have auto-signin on your system   First  the cheap  easy way that puts it all on someone else  If you make your site support logging in with  say  your google  account  you probably have a streamlined google  button that will log the user in if they are already signed into google  I did that here to answer this question  as I am always signed into google   If you want the user automatically signed in if they are already signed in with a trusted and supported authenticator  and checked the box to do so  have your client-side scripts perform the code behind the corresponding  sign-in with  button before loading  just be sure to have the server store a unique ID in an auto-signin table that has the username  session ID  and the authenticator used for the user  Since these sign-in methods use AJAX  you are waiting for a response anyway  and that response is either a validated response or a rejection  If you get a validated response  use it as normal  then continue loading the logged in user as normal  Otherwise  the login failed  but don t tell the user  just continue as not logged in  they will notice  This is to prevent an attacker who stole cookies  or forged them in an attempt to escalate privileges  from learning that the user auto-signs into the site   This is cheap  and might also be considered dirty by some because it tries to validate your potentially already signed in self with places like Google and Facebook  without even telling you  It should  however  not be used on users who have not asked to auto-signin your site  and this particular method is only for external authentication  like with Google  or FB   Because an external authenticator was used to tell the server behind the scenes whether or not a user was validated  an attacker cannot obtain anything other than a unique ID  which is useless on its own  I ll elaborate    User  joe  visits site for first time  Session ID placed in cookie  session   User  joe  Logs in  escalates privileges  gets new Session ID and renews cookie  session   User  joe  elects to auto-signin using google   gets a unique ID placed in cookie  keepmesignedin   User  joe  has google keep them signed in  allowing your site to auto-signin the user using google in your backend  Attacker systematically tries unique IDs for  keepmesignedin   this is public knowledge handed out to every user   and is not signed into anywhere else  tries unique ID given to  joe   Server receives Unique ID for  joe   pulls match in DB for a google  account  Server sends Attacker to login page that runs an AJAX request to google to login  Google server receives request  uses its API to see Attacker is not logged in currently  Google sends response that there is no currently signed in user over this connection  Attacker s page receives response  script automatically redirects to login page with a POST value encoded in the url  Login page gets the POST value  sends the cookie for  keepmesignedin  to an empty value and a valid until date of 1-1-1970 to deter an automatic attempt  causing the Attacker s browser to simply delete the cookie  Attacker is given normal first-time login page    No matter what  even if an attacker uses an ID that does not exist  the attempt should fail on all attempts except when a validated response is received   This method can and should be used in conjunction with your internal authenticator for those who sign into your site using an external authenticator              Now  for your very own authenticator system that can auto-signin users  this is how I do it   DB has a few tables   TABLE users  UID - auto increment  PK username - varchar 255   unique  indexed  NOT NULL password hash - varchar 255   NOT NULL       Note that the username is capable of being 255 characters long  I have my server program limit usernames in my system to 32 characters  but external authenticators might have usernames with their  domain tld be larger than that  so I just support the maximum length of an email address for maximum compatibility   TABLE sessions  session id - varchar     PK session token - varchar     NOT NULL session data - MediumText  NOT NULL   Note that there is no user field in this table  because the username  when logged in  is in the session data  and the program does not allow null data  The session id and the session token can be generated using random md5 hashes  sha1 128 256 hashes  datetime stamps with random strings added to them then hashed  or whatever you would like  but the entropy of your output should remain as high as tolerable to mitigate brute-force attacks from even getting off the ground  and all hashes generated by your session class should be checked for matches in the sessions table prior to attempting to add them   TABLE autologin  UID - auto increment  PK username - varchar 255   NOT NULL  allow duplicates hostname - varchar 255   NOT NULL  allow duplicates mac address - char 23   NOT NULL  unique token - varchar     NOT NULL  allow duplicates expires - datetime code   MAC addresses by their nature are supposed to be UNIQUE  therefore it makes sense that each entry has a unique value  Hostnames  on the other hand  could be duplicated on separate networks legitimately  How many people use  Home-PC  as one of their computer names  The username is taken from the session data by the server backend  so manipulating it is impossible  As for the token  the same method to generate session tokens for pages should be used to generate tokens in cookies for the user auto-signin  Lastly  the datetime code is added for when the user would need to revalidate their credentials  Either update this datetime on user login keeping it within a few days  or force it to expire regardless of last login keeping it only for a month or so  whichever your design dictates   This prevents someone from systematically spoofing the MAC and hostname for a user they know auto-signs in  NEVER have the user keep a cookie with their password  clear text or otherwise  Have the token be regenerated on each page navigation  just as you would the session token  This massively reduces the likelihood that an attacker could obtain a valid token cookie and use it to login  Some people will try to say that an attacker could steal the cookies from the victim and do a session replay attack to login  If an attacker could steal the cookies  which is possible   they would certainly have compromised the entire device  meaning they could just use the device to login anyway  which defeats the purpose of stealing cookies entirely  As long as your site runs over HTTPS  which it should when dealing with passwords  CC numbers  or other login systems   you have afforded all the protection to the user that you can within a browser   One thing to keep in mind  session data should not expire if you use auto-signin  You can expire the ability to continue the session falsely  but validating into the system should resume the session data if it is persistent data that is expected to continue between sessions  If you want both persistent AND non-persistent session data  use another table for persistent session data with the username as the PK  and have the server retrieve it like it would the normal session data  just use another variable   Once a login has been achieved in this way  the server should still validate the session  This is where you can code expectations for stolen or compromised systems  patterns and other expected results of logins to session data can often lead to conclusions that a system was hijacked or cookies were forged in order to gain access  This is where your ISS Tech can put rules that would trigger an account lockdown or auto-removal of a user from the auto-signin system  keeping attackers out long enough for the user to determine how the attacker succeeded and how to cut them off   As a closing note  be sure that any recovery attempt  password changes  or login failures past the threshold result in auto-signin being disabled until the user validates properly and acknowledges this has occurred   I apologize if anyone was expecting code to be given out in my answer  that s not going to happen here  I will say that I use PHP  jQuery  and AJAX to run my sites  and I NEVER use Windows as a server    ever

User · Answer

Implementing a  Keep Me Logged In  feature means you need to define exactly what that will mean to the user  In the simplest case  I would use that to mean the session has a much longer timeout  2 days  say  instead of 2 hours  To do that  you will need your own session storage  probably in a database  so you can set custom expiry times for the session data  Then you need to make sure you set a cookie that will stick around for a few days  or longer   rather than expire when they close the browser   I can hear you asking  why 2 days  why not 2 weeks    This is because using a session in PHP will automatically push the expiry back  This is because a session s expiry in PHP is actually an idle timeout    Now  having said that  I d probably implement a harder timeout value that I store in the session itself  and out at 2 weeks or so  and add code to see that and to forcibly invalidate the session  Or at least to log them out  This will mean that the user will be asked to login periodically  Yahoo  does this

User · Answer

I don t understand the concept of storing encrypted stuff in a cookie when it is the encrypted version of it that you need to do your hacking   If I m missing something  please comment   I am thinking about taking this approach to  Remember Me    If you can see any issues  please comment    Create a table to store  Remember Me  data in - separate to the user table so that I can log in from multiple devices  On successful login  with Remember Me ticked    a  Generate a unique random string to be used as the UserID on this machine  bigUserID  b  Generate a unique random string  bigKey  c  Store a cookie   bigUserID bigKey  d  In the  Remember Me  table  add a record with  UserID  IP Address  bigUserID  bigKey If trying to access something that requires login   a  Check for the cookie and search for bigUserID  amp  bigKey with a matching IP address  b  If you find it  Log the person in but set a flag in the user table  soft login  so that for any dangerous operations  you can prompt for a full login  On logout  Mark all the  Remember Me  records for that user as expired    The only vulnerabilities that I can see is    you could get hold of someone s laptop and spoof their IP address with the cookie  you could spoof a different IP address each time and guess the whole thing - but with two big string to match  that would be   doing a similar calculation to above   I have no idea   huge odds

User · Answer

My solution is like this  It s not 100  bulletproof but I think it will save you for the most of the cases   When user logged in successfully create a string with this information    data    SALT         hash User Agent          username                               LoginTimestamp        SALT    Encrypt  data  set type to HttpOnly and set cookie   When user come back to your site  Make this steps    Get cookie data  Remove dangerous characters inside cookie  Explode it with   character   Check validity  If cookie is older than X days then redirect user to login page  If cookie is not old  Get latest password change time from database  If password is changed after user s last login redirect user to login page  If pass wasn t changed recently  Get user s current browser agent  Check whether  currentUserAgentHash    cookieUserAgentHash   IF agents are same go to next step  else redirect to login page  If all steps passed successfully authorize username    If user signouts  remove this cookie  Create new cookie if user re-logins

[php] "Keep Me Logged In" - the best approach

Examples related to php

Examples related to security

Examples related to session

Examples related to remember-me