Re: Best way to remember a logged in user

From: Shawn Wilson (shawn_at_glassgiant.com)
Date: 12/26/03 

Date: Fri, 26 Dec 2003 10:41:58 -0400

Joshua Beall wrote:
>
> "Shawn Wilson" <shawn@glassgiant.com> wrote in message
> news:3FEC3426.65E163C5@glassgiant.com...
> > Joshua Beall wrote:
> > Usually, I find the best way is with sessions - that's what they were
> invented
> > for. Upon logging in, set a variable like $_SESSION['username']. If they
> click
> > a logout button or try to login unsuccessfully, unset it.
> >
> > In your scripts, just be sure to check if $_SESSION['username'] is set.
>
> The problem with that is, once the session expires, the user is no longer
> logged in.
>
> I already have a complete authentication engine setup, using sessions, but I
> want to know what the best way to implement a "remember me" feature - so
> that when a user comes back to my site, it remembers who they are. Ebay,
> Yahoo, Amazon, etc., all implement this feature. How do they remember who I
> am? Surely they do not leave the session active for a user who has not
> visited in over a week, do they? It must be through a cookie then - but
> what information do they store?
>
> (goes off to hunt through cookies and examine what they send...)
>
> Hmm, for Amazon, they are storing my session id, something called "x-main",
> "ubid-main", and "session-id-time". The expiration date for all these
> cookies is March 15, 2004. Does Amazon then just not expire sessions for 6
> months? Does not this clog up the server's memory with lots of session
> data?
>
> I guess the solution for this would be to implement a custom session record
> handler, that serializes the data and stores it in a database or a file, so
> that after garbage collection happens, it can still be recovered from the
> database?
>
> I am looking through some cookies from an Invisionboard Forum site that I
> visit, and it looks like, in order to remember me, they store my user ID,
> and the md5 hash of my password. While this is pretty hard to translate
> back into a username/password, I suppose this is still a pretty big security
> risk, because all someone has to do in order to login as you is put copy
> those cookies on their machine, with those values?

Ah, I see. Any site that lets you stay logged in is a security risk, IMO. Now
that you mention it, Hotmail does the same thing.

If you just want to remember the login I guess it would be easy enough to set a
cookie with the username and uniqid() (which would also have to be stored with
the account info server-side). Then read the cookie and compare it to username,
uniqid in the db. The uniqid should be changed periodically, to prevent
someone's who has hacked it from using it for too long. Of course, if someone
read the cookie they could easily copy it to their own computer and use the
account until the uniqid was changed.

If you wanted to remember a number of session variables as well, you could make
a custom session handler, as you suggested.

I really hate the idea of storing pw hashes in a cookie, as it's too easy to get
the pw, assuming access to the computer (as in an office setting or public
terminal) and bad passwords (dictionary passwords). I think that for any method
discussed so far, you could just copy the cookie file onto your own computer to
access the account. It's bad enough to have someone access your account - it's
worse for them to learn your password.

If you go with a solution that allows you to stay logged in over a long period
of time, I would suggest making it optional (have a preference section where a
user can decline to use that feature). It makes me nervous when sites do that
and, being human, I often forget to logout before closing the browser =o)

Regards,
Shawn 

-- 
Shawn Wilson
shawn@glassgiant.com
http://www.glassgiant.com
Quantcast