Page 1 of 1
Cookies & security
Posted: Mon May 27, 2002 5:10 pm
by metalman
Hello,
I need to set a cookie with an ID value (I have user system, each user have unique ID) for each user that log into the system.
but, im afraid that people will change their value to other id and will log into other people account, here an example :
Code: Select all
<?php
#check the cookie
if(!isset($_COOKIEїid]))
die("only for members !!!! please login");
#get the user data
$user_data = mysql_query("SELECT * FROM users WHERE id='$_COOKIEїid]'");
?>
the problem is that when a hacker will see this, he will change the cookie value to something else and will log into other people account
Can I somehow encrypte cookies so people wont be able to change their content ?
btw, I DONT want to use session...
Thanks in advance.
Posted: Mon May 27, 2002 5:18 pm
by fatal
Posted: Mon May 27, 2002 6:15 pm
by metalman
thanx !!!
im triend to do something like this :
Code: Select all
<?php
srand((double)microtime()*1000000);
$id_cookie = md5(rand(0,9999999));
# $id_unique is the unique id for each user from the databse
if( login info is OK )
{
setcookie("$id_cookie","$id_unique",time()+3600,"/",$SERVER_NAME);
}
?>
Now, is it safe ? I want to do something like this :
Code: Select all
<?php
#get the user data
$user_data = mysql_query("SELECT * FROM users WHERE id='$_COOKIEї$id_cookie]'");
?>
is it safe ?
THANKS
Posted: Mon May 27, 2002 10:20 pm
by fatal
You should have the encrpted ID in the database then have the un-encripted ID stored in the cookie.
Posted: Mon May 27, 2002 10:27 pm
by volka
why do you have to do this at all?
after a user logged in with name/password you can read the ID from the database and store it in $_SESSION.
If you want to achieve a 'long-term' login (until the user manually logs out) you may store a login-id for a user in the database. This login-id has to be generated when a user logged in, sent as cookie and erased from the database when the user logged out.
Whenever you do a login check, check against the session data and the cookie data to be valid. Only if both fail deny access.
I think it's no good to store vital, long-term data (like the user id) crypted/hashed or not on the client side.
Posted: Mon May 27, 2002 11:14 pm
by metalman
You should have the encrpted ID in the database then have the un-encripted ID stored in the cookie.
Ok, thanx...
why do you have to do this at all?
after a user logged in with name/password you can read the ID from the database and store it in $_SESSION.
If you want to achieve a 'long-term' login (until the user manually logs out) you may store a login-id for a user in the database. This login-id has to be generated when a user logged in, sent as cookie and erased from the database when the user logged out.
Whenever you do a login check, check against the session data and the cookie data to be valid. Only if both fail deny access.
I think it's no good to store vital, long-term data (like the user id) crypted/hashed or not on the client side.
Sessions is bad ! why ?
read this :
Hello,
I have very wierd problem :
I use session to manage users and I have this structure of the page :
-----
include("db.php");
include("header.php");
bla bla
include("footer.php");
-----
in the db.php I have :
----
session_start();
#some mysql connect stuff
----
I use session with the $_SESSION array (cheking if registered[isset($_S...)]
and registering...)
and all work fine....
but sometimes the page loading is very very very slow (and its a really
really fast host) and when I removing session_start(); from the top of the
page, the page load normaly.
the PHP version is 4.1.1, someone have an idea ?
thanks in advance,
Dima.
this was sent to the PHP mail list, people tried to help but no one solve the problem

Posted: Mon May 27, 2002 11:34 pm
by volka
hmmm...perhaps because no one else experienced the problem?
it slows down a bit if you set session.save_path = /dev/fd0
ok ok, then forget about the session - it's unnecessary. Use the cookie data and reject access if the login-id is unset or unequal to the id in the database.
Probably we're speaking about the same thing but I just wanted to emphasize that the field 'id' in the database should be volatile if it is the only mechanism for login purposes.
Think about it (at least twice) before you store login data that never changes client-side.
Posted: Tue May 28, 2002 3:07 am
by mikeq
fatal wrote:You should have the encrpted ID in the database then have the un-encripted ID stored in the cookie.
Would it not be the other way round? Lets say a user has a simple ID of '212' and this was stored in a cookie a hacker could easily change his cookie ID from say '211' to '212' and would have access to that users records. If stored in the cookie as an encrypted ID it may look something like '$hf8*7623!4' or whatever, the hacker without knowing how this was created would have a more difficult time trying to change it.
So..
Encrypted ID in the cookie and un-encrypted ID in the database, get the users cookie, decrypt it and compare against the database, that would be my guess.
Mike
Posted: Tue May 28, 2002 4:34 am
by metalman
OK, thank you all people !!
someone replied me in the mail list, here is the solution for the session problem
Hi
PHP's sessions are blocking, i.e. until a session is closed, all other calls to
session_start() are pending. If you don't close a session explicitely, it
remains opened until the script is terminated.
The solution is to close a session as soon as possible (session_write_close) or
use non-blocking read-only sessions (session_readonly instead of session_start)
in case you don't need to modify registered variables.
Tom
and now I also know how to do this with cookies
thank you
