>How could a "malicious user" gain access to a cookie stored somewhere in...
Easily, if they sleep with the user.
>By malicious user i was referring to someone who seeks to gain access
to other people's accounts by first creating an account and storing a
cookie, then editing the cookie so that the website automatically logs
them in as someone else. How can this be prevented?
Any user can trivially set any darn cookie they want to any value
they want on their own computer. The procedure is simple for most
browsers: (a) shut down the browser, (b) edit the file the cookies
are kept in (usually it's a text file and the format is pretty
obvious), and (c) start up the browser. I've heard rumors about a
browser that lets you do it by clicking on "set cookie" and following
the prompts. It's also real easy for PHP to use CURL to pull a copy
of a web page from any other web site with any set of cookies you want.
If you were thinking of setting a cookie containing the user name,
but not the password, assuming the cookie is set that way only if
the password given is correct, your security design is incredibly
stupid (It ranks right up there with the sign on the bank vault,
also advertised on national television, asking people to not steal
from it because it's unlocked and the guard is blind). On the other
hand, if the cookie contains the user name and password in plain
text, you're making it easy for anyone to look at the stored cookie
and replicate it on their own computer.
An approach that might work is to put in the cookie the following pieces:
1. the user name
2. a time stamp
3. a secure cryptographic hash of (a) the username, (b) the time
stamp, and (c) a secret string held by the site.
If a user comes back, validate the cookie:
1. Check the hash. The hash of the username from the cookie,
the time stamp from the cookie, and the secret string
(NOT in the cookie) should match the hash in the cookie.
2. Check the time stamp. If the cookie is too old, it's stale,
so don't let them log in.
3. Check the user name. It had better correspond to a user
that exists.
If the bad guy takes an existing cookie and tries to edit it to refer
to a different user, the hash won't match. If the bad guy steals a copy
of a really old cookie (say, from a traded-in hard disk), it will fail
the time stamp check.
Often, you'd re-write the cookie with a new time stamp every hit, so as
long as they keep clicking, they'll stay logged in.
How long is "too old"? It needs to be long than you expect users to go
between logins. It should be shorter to protect against stolen cookies.