By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,614 Members | 1,680 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,614 IT Pros & Developers. It's quick & easy.

is it safe to store a cookie user id as a login for my site

P: n/a
hi

i have a php site which allows users to save a cookie on their
computer which stores their user id details and allows them to auto-
login.

i'm wondering whether this is safe, is it possible for a malicious
user to find that cookie and change its value and therefore auto-login
as someone else? and if so how can this be prevented?

thanks

marc

Feb 16 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"monomaniac21" wrote
hi
G'day.
i have a php site which allows users to save a cookie on their
computer which stores their user id details and allows them to auto-
login.

i'm wondering whether this is safe, is it possible for a malicious
user to find that cookie and change its value and therefore auto-login
as someone else? and if so how can this be prevented?
How could a "malicious user" gain access to a cookie stored somewhere in
your your users computer, unless they break into your users house? My
browser regularly asks me if I wish it to "remember" my userid/password
detailss for next time. Often I tell it to do so.

Then again your user may be just silly enough to store your cookie on the
public libraries computer. Their problem then IMHO.
Feb 16 '07 #2

P: n/a
monomaniac21 schrieb:
hi

i have a php site which allows users to save a cookie on their
computer which stores their user id details and allows them to auto-
login.

i'm wondering whether this is safe, is it possible for a malicious
user to find that cookie and change its value and therefore auto-login
as someone else? and if so how can this be prevented?

thanks

marc
You could store one half of the user's password hash in the cookie. When
he come back, you compare it to the hash in the db. Works for me :-)
Feb 16 '07 #3

P: n/a
>
How could a "malicious user" gain access to a cookie stored somewhere in...
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?
Feb 16 '07 #4

P: n/a
"monomaniac21" wrote>
>>
How could a "malicious user" gain access to a cookie stored somewhere
in...

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?
Er, you can't, or, perhaps, you don't need to.

I could, for instance:

a) Create an account and then hack the cookie so as to use some other
persons credentials to log in, after guessing their credentials.

b) Use your standard login form to log in using some other persons
credentials, after guessing their credentials.

Where is the problem?

On the other hand if you store stuff in your cookie that allows it to be
hacked then your design is flawed.
Feb 16 '07 #5

P: n/a
Mike Roetgers wrote:
monomaniac21 schrieb:
>hi

i have a php site which allows users to save a cookie on their
computer which stores their user id details and allows them to auto-
login.

i'm wondering whether this is safe, is it possible for a malicious
user to find that cookie and change its value and therefore auto-login
as someone else? and if so how can this be prevented?

thanks

marc
You could store one half of the user's password hash in the cookie. When
he come back, you compare it to the hash in the db. Works for me :-)
Or, better yet, hash the password in the database a second time and
store that has in the cookie. When they do the cookie login compare the
cookie they send with the database password (after you've hashed it, of
course).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Feb 16 '07 #6

P: n/a
>i have a php site which allows users to save a cookie on their
>computer which stores their user id details and allows them to auto-
login.

i'm wondering whether this is safe, is it possible for a malicious
user to find that cookie and change its value and therefore auto-login
as someone else? and if so how can this be prevented?

How could a "malicious user" gain access to a cookie stored somewhere in
your your users computer, unless they break into your users house? My
Easy: your user LIVES WITH (or worse, sleeps with AND lives with)
the malicious user. Or his kids invite the malicious user (aka
neighbor kid) in. Not all users are nerds with no friends.
Sometimes warring siblings have to share a computer.

Laptops are easy to steal. Just listen to the news: how often is
a laptop with government classified information or sensitive financial
information on it reported missing? I suspect it's especially easy
to steal laptops at airports. My Palm also contains a web browser
and it's not that hard to lose it.
>browser regularly asks me if I wish it to "remember" my userid/password
detailss for next time. Often I tell it to do so.
>Then again your user may be just silly enough to store your cookie on the
public libraries computer. Their problem then IMHO.
Feb 17 '07 #7

P: n/a
>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.

Feb 17 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.