Best way to remember a logged in user

[Joshua Beall]

Hi All,

What is the best way to use a cookie to remember a logged in user? Would
you store the username and password in two separate cookies? Should the
password be plain text? Hashed? Not there at all?

Any feedback would be helpful. Thanks!

-Josh

[Shawn Wilson]

Joshua Beall wrote:

Hi All,

What is the best way to use a cookie to remember a logged in user? Would
you store the username and password in two separate cookies? Should the
password be plain text? Hashed? Not there at all?

Any feedback would be helpful. Thanks!

-Josh

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.

Or, if you wanted to and you're using Apache, you could use htaccess/htpasswd.
Then, in your scripts, just check $_SERVER['REMOTE_USER'] to get the user name.
Though that does have some drawbacks if you have many users - it gets slow.
Also, it uses the browser's default username/password box, which is ugly and
doesn't allow you to interact with the user.

You should never send anyone's password to a cookie. That info is stored on the
person's hard drive and could be easily read.

Regards,
Shawn
--
Shawn Wilson
sh***@glassgiant.com
http://www.glassgiant.com

[Joshua Beall]

"Shawn Wilson" <sh***@glassgiant.com> wrote in message
news:3F***************@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?

-jb

[Shawn Wilson]

Joshua Beall wrote:

"Shawn Wilson" <sh***@glassgiant.com> wrote in message
news:3F***************@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
sh***@glassgiant.com
http://www.glassgiant.com

[Eagle]

Without more specific information on the purposes of your particular
application I would suggest to make use of php excellent session
handling. Once verified a user, you can maintain this verified state
throughout all subsequent page visits making use of a session.

Get the details at http://es.php.net/manual/en/ref.session.php
On Fri, 26 Dec 2003 02:42:40 GMT, "Joshua Beall"
<jb****@donotspam.remove.me.heraldic.us> wrote:

Hi All,

What is the best way to use a cookie to remember a logged in user? Would
you store the username and password in two separate cookies? Should the
password be plain text? Hashed? Not there at all?

Any feedback would be helpful. Thanks!

-Josh

Eagle

(I very much appreciate your contributions.
Please do not reply to my email-address since it is deactivated due to tons of Spam I received.
Thanks a ton)

[Eagle]

Without more specific information on the purposes of your particular
application I would suggest to make use of php excellent session
handling. Once verified a user, you can maintain this verified state
throughout all subsequent page visits making use of a session.

Get the details at http://es.php.net/manual/en/ref.session.php
On Fri, 26 Dec 2003 02:42:40 GMT, "Joshua Beall"
<jb****@donotspam.remove.me.heraldic.us> wrote:

Hi All,

What is the best way to use a cookie to remember a logged in user? Would
you store the username and password in two separate cookies? Should the
password be plain text? Hashed? Not there at all?

Any feedback would be helpful. Thanks!

-Josh

Eagle

(I very much appreciate your contributions.
Please do not reply to my email-address since it is deactivated due to tons of Spam I received.
Thanks a ton)

[Joshua Beall]

"Shawn Wilson" <sh***@glassgiant.com> wrote in message >

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).

This problem is an obvious one that I have been thinking about and trying to
figure out what the best way to deal with is, but here is another question:
Is there any way for a site to harvest cookies remotely? I.e., is there any
way for a something.com to look at mysite.com's cookies?

[Roberto]

> Without more specific information on the purposes of your particular

application I would suggest to make use of php excellent session
handling.

I'm an absolute beginner with this topic, trying to acquire knowledge about
the most secure method.
According to you, this method is more secure then cookies and URL
techniques? I read that if the page is stored in a ISP server shared by many
users, the session's file stored in /tmp could be accessed by malicious
users.

thanks
Roberto

[Gordon Burditt]

>> 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,
There is a VERY LARGE difference between "remembers who they are"
and "stays logged in", depending on what your application is. When
a user is logged in, WHAT CAN THEY DO? Spend money using a remembered
credit card number? Access their medical history? Change the US
national threat level? Launch missiles? Shut down the national
power grid? Transfer funds from a bank account? In that case, I
suggest that sessions be rather short (e.g. 10 minutes). You can
update the life of the session on each hit, so the user has to go
away for 10 minutes or take a long time reading the page before the
session times out. If all being logged in means is that they can
read your porn site until their subscription expires, then it's OK
to just set it to when their current payment runs out.

If "remember who they are" means part of a web page says "Hello,
Bob. You have a new message. Please log in to read it.", or it
just allows you to track click trails and gives no privileges
whatever, then feel free to have sessions last millennia.

Note that a "remembers who they are" feature with a long expire
time can be seriously annoying if you've got two people sharing one
computer and there are logical reasons why, for example, father and
daughter should keep their use of a dating site separate (hopefully
they are not dating the same people). In that case, AT LEAST provide
an ability to log out one user and log in as another.

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?
You can write alternate session handlers that store session parameters
in a database rather than temporary files. Someplace like Amazon
might well want to keep open sessions for say, twenty years, and
along with that, save records of EVERY hit on their site from those
users. 1 megabyte per every customer they have ever had? This is
trivial for a decent database setup (especially for a company as
big as Amazon). Only a small fraction of that would be used or
changed on any page.
All you need in a cookie is a session ID. All the rest of the data
is kept with the session (or in a database referenced from the
session), where you can get to it even if the user never visits
again. You probably wouldn't want to keep the entire lifetime order
history in a session. Keep the account number in a session, and
reference order history by account number in other parts of the
database, so a "check order history" page would likely need to
reference the database explicitly.

You would need some way for a user to get back the session cookie
(or at least association with the same account) if he loses it (or
accesses from a different computer). This is often done by
username/password. Banks and health insurance companies often use
SSN (BOO! HISS!). Radio Shack at least used to use telephone
number at its physical stores. Termite companies often use address
(the house stays the same, usually, even if the occupants/owners
don't).
(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?
If they intend to really track this data (keep it permanently),
they have ONE session per customer, rather than multiple sessions
over a period of 6 months. This may actually save data storage.
And it's more valuable for marketing invasion-of-privacy if all
the sessions of a given customer are associated.
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?
Yes.

A key to security with sessions is that a valid session ID shouldn't be
guessable. Issuing sequential session numbers is a really BAD idea,
as they are easily guessed. Also, they shouldn't last very long, so
by the time someone DOES guess one, it's expired.
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?

*ANY* method of using cookies to establish a current login is
vulnerable if someone can steal the cookies. The longer the session
timeout, the bigger the problem. However, who is likely to be able
to steal your cookies? Your family and/or coworkers with whom you
share a computer. Are they a threat? Yes, if it's your teenage
son trying to get into your porn account. The evil hacker on the
phone pole outside your house tapping your line (do you think he
gets enough cookies that way to make it worth his while? I doubt
it.) The CIA or the KGB? Do they REALLY care about your porn site
or bank account password? They could confiscate the entire bank
or porn site if they wanted.

If you're going to include the MD5 hash of something, I suggest including
a site-specific secret in the hash. That way, a cracker can't
take the hash of obvious guesses for a password, make his own cookies,
and try them.

Gordon L. Burditt

[DutchFish]

> I'm an absolute beginner with this topic, trying to acquire knowledge
about

the most secure method.
According to you, this method is more secure then cookies and URL
techniques? I read that if the page is stored in a ISP server shared by many users, the session's file stored in /tmp could be accessed by malicious
users.

you can set the path where your session data is stored by:

session_save_path('/usr/yourpath');

read also:
http://nl3.php.net/manual/en/functio...-save-path.php

Kind regards,

DutchFish

[CountScubula]

"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message news:<Ae*******************@nwrddc02.gnilink.net>. ..

Hi All,

What is the best way to use a cookie to remember a logged in user? Would
you store the username and password in two separate cookies? Should the
password be plain text? Hashed? Not there at all?

Any feedback would be helpful. Thanks!

-Josh

This is a little trick I use (sometimes my sites scale multiple
servers)

I set a couple of cookies, all with the same expire time
1 = userid
2 = key that is encrypted, represents login is invalid after timestamp
3 = key that is encrypted, represents browser user-agent

with that, even if somone sniffed the line or captured the cookies,
they will not be able to reuse the cookie info

becouse the scripts check if everything matches, does the cookie of
the useragent match the browser that is being used? is the timeout
cookie expired?

I learned to do this one time while getting paid to write automation
software getting data access was granted using session id in a cookie,
well I wrote some software that didn't let the cookie expire and I was
able to gain access to the data even after the user account was
closed.

This was years ago, it was for a client that wanted to automate
retrieving data from monster.com, he did pay monster for the account,
but the software worked after the account was closed due to loose
programming and forethough.

Mike Bradley
http://gzen.myhq.info -- free online php tools

[R. Rajesh Jeba Anbiah]

"Joshua Beall" <jb****@donotspam.remove.me.heraldic.us> wrote in message news:<Ae*******************@nwrddc02.gnilink.net>. ..

Hi All,

What is the best way to use a cookie to remember a logged in user? Would
you store the username and password in two separate cookies? Should the
password be plain text? Hashed? Not there at all?

Any feedback would be helpful. Thanks!

http://martin.f2o.org/php/login

--
"Success = 10% sweat + 90% tears"
Email: rrjanbiah-at-Y!com

[FLEB]

Regarding this well-known quote, often attributed to Joshua Beall's famous
"Fri, 26 Dec 2003 18:29:36 GMT" speech:

(snip original question)

This problem is an obvious one that I have been thinking about and trying to
figure out what the best way to deal with is, but here is another question:
Is there any way for a site to harvest cookies remotely? I.e., is there any
way for a something.com to look at mysite.com's cookies?

Possibly. If your users can somehow wedge some code, even a small bit of
it, onto your site, you've got a potential problem.

For example, I'm on a music purchase service (to be unnamed), that has a
big insecurity in the messageboards and user best-of lists. The problem is
that they don't screen for HTML tags. All I'd need to do is make a simple
JavaScript that --

1.) "Document.write"s a form with a bunch of hidden elements. I'd do this
in script rather than just put it in the message, since their messageboards
have tight limits on message size.

2.) Copies the "document.cookie" variable (this has all the cookies that
are within the current page's scope) into the FORM HIDDEN element.

3.) Submits the form to a script on my site.

-- Then, I place this on my webspace, make a simple SCRIPT SRC="..." tag
linking to it, and boom, a handy-dandy cookie stealer.

The thing about this problem is that it can crop up in odd places, too...
Sites that use user input to make titles or other small information (I
recall a font-retailer's site that used a GET request variable to write out
the title of the page). There might be a slim chance, if username checking
isn't handled well, that people could put tags into a username. If anything
the user enters gets displayed to the general public, it might be a risk.

Best off not to put sensitive info in cookies, then.

--
-- Rudy Fleminger
-- [e-mail]
(put "Hey!" in the Subject line for priority processing!)
-- http://www.pixelsaredead.com

[CountScubula]

"FLEB" <so*********@mmers.and.evil.ones.will.bow-down-to.us> wrote in
message news:14****************************@40tude.net...

Best off not to put sensitive info in cookies, then.
--
-- Rudy Fleminger

if its sensitive, encrypt it, there are sever simple ways to do it, and one
can always put an index in the cookie, which point to real data on the
server.

--
Mike Bradley
http://gzen.myhq.info -- free online php tools

[Joshua Beall]

"CountScubula" <[e-mail]> wrote in message
news:e_*****************@newssvr29.news.prodigy.co m...

if its sensitive, encrypt it, there are sever simple ways to do it, and one can always put an index in the cookie, which point to real data on the
server.

The fundamental problem is, though, that in order to login as somebody else,
you only need to steal their cookies. This is easily doable if it is an
office computer, lab computer, library computer, etc.

Someone suggested hashing the user agent and comparing it, which could work,
although it is no guarantee. IP checking will not work since IPs can
change, and with AOL, for instance, often change right in the middle of an
active session!

Any other ideas?

[CountScubula]

> Someone suggested hashing the user agent and comparing it, which could
work,

although it is no guarantee. IP checking will not work since IPs can
change, and with AOL, for instance, often change right in the middle of an
active session!

Any other ideas?

I believe that was me talking about the user agent, if you added that with a
couple other things it might work.

You could also encrypt a timeout, and if that is not a valid cookie, no
access
I did this for someone in another post.
something along the lines of

$limit = 30;
$timeOut = time() + $limit;
$cookieTimeOut = your_fav_way_to_encrypt($timeOut);

--
Mike Bradley
http://gzen.myhq.info -- free online php tools