Page 1 of 1

Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 7:53 am
by JAB Creations
I've been working on a PHP/MySQL membership/control panel sort of script for a couple weeks now. I sign in (authenticates via an IMAP account for myself, through MySQL for others) and since sessions end when the browser is closed I'm wondering what are some secure ways to automatically sign someone back in based on their cookie. Do we check for the same IP address for example? I know we can't trust client data but obviously being automatically signed in after browser/closed/session ended is a common feature online. I'm not necessarily looking for code so much as the logic behind this though I posted here instead of the theory forum because I want to keep the focus on security.

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 8:15 am
by arjan.top
i would do this:
use for example username, email and id, hash it
save the result in the user table and in the cookie

then check for the matching value (cookie=database)

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 8:40 am
by JAB Creations
I'm not very familiar with hashes. Would storing a number generated by this be acceptable as far as security is concerned?

Code: Select all

$hash = rand(101, 998);
I could read the cookie, explode it (separated by commas or something else), and determine if the credentials are acceptable or not.

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 9:00 am
by arjan.top
if you want to go the rand way, use uniqid instead

$hash = md5(uniqid(rand(), true));

use some hash function, md5, sha1 or go with something better like sha256

$hash = hash('sha256', uniqid(rand(), true)); -> you need php >= 5.1.2 for that
I could read the cookie, explode it (separated by commas or something else), and determine if the credentials are acceptable or not.
i dont know what you mean ...
why explode?

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 10:10 am
by JAB Creations
arjan.top wrote:i dont know what you mean ...
why explode?
I mean in this sense of creating the cookie...

Code: Select all

$_COOKE['remember_me'] = $name.','.$id.','.$hash;
I'm not sure *why* I want to use a hash? I don't see the advantage over simply using rand. I'm not trying to be difficult, just objective. Does it use considerably more resources? Is the security different great enough to justify whatever the load difference? These are the things running through my head. Thanks for your suggestions!

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 10:30 am
by arjan.top
do not store any user information into cookies

what i suggested in my first reply was this:
$hash = md5($username.$email.$userid);
then save this into cookie (for example auto_login) and the user table

then when user comes to your site, you check the cookie auto_login, if there is any, you match it wo the user table

the second approach would be just to use uniqid(), the point is that you get unique identifier for the user

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 10:34 am
by JAB Creations
Ok cool...so in essence you are suggesting...

1.) Make a hash based off of certain things (username, ID, maybe add a rand number to always make a random hash for each individual session so it doesn't get stuck on a specific hash everytime).

2.) Check the hash per login.

I also plan on seeing if the IP has changed and forcing the user to sign in manually if the IP is different from the last IP. I have three column/rows, registered IP, last IP, current IP right now.

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 10:41 am
by arjan.top
JAB Creations wrote:Ok cool...so in essence you are suggesting...

1.) Make a hash based off of certain things (username, ID, maybe add a rand number to always make a random hash for each individual session so it doesn't get stuck on a specific hash everytime).

2.) Check the hash per login.
yes, switch rand with uniqid, rand is not random enough (it can be the same from time to time)
I also plan on seeing if the IP has changed and forcing the user to sign in manually if the IP is different from the last IP. I have three column/rows, registered IP, last IP, current IP right now.
that i would not do, ip can change

in my country nost of the ISP's change the ip every 24 hours, the choice is yours

Re: Secure method of recreating session via a cookie?

Posted: Mon Aug 18, 2008 10:54 am
by JAB Creations
It depends on what ISP you have and what part of the country you live in. For example I might as well claim I have a static IP address because it hasn't changed for several months. However worse case scenario they have to use autocomplete...meaning their user/pass are auto-filled so they just have to press a button. I'm not going too deep in to details right now as this is my first real attempt at what I'm doing to give me a greater basis to work off of in the future.

php.net/uniqid ...ok checked it out and I now completely agree with your suggestion over rand! Time to implement all of this now.

Re: Secure method of recreating session via a cookie?

Posted: Tue Aug 19, 2008 3:35 am
by Mordred
Wow, some dangerous (and some not) misconceptions were said here. Commenting in chronological order (not by severity)
JAB wrote:Would storing a number generated by this be acceptable as far as security is concerned?
$hash = rand(101, 998);
No, this is bad: it has only ~900 possibilities, which are easy to bruteforce.
arjan wrote:$hash = md5(uniqid(rand(), true));
use some hash function, md5, sha1 or go with something better like sha256
In this case, there is little-to-none security benefit in choosing one hash over another, as the entropy of the hash will be no greater than the entropy of the underlying random. uniqid() generates at most 23 hex chars, i.e. 92 bits of entropy. Using a 128 bit MD5 or a 256 bit SHA256 makes no difference, the entropy of the hash will be still 92 bits. (Actually even less, as parts of the uniqid() are based on the system time)
JAB wrote:I'm not sure *why* I want to use a hash? I don't see the advantage over simply using rand.
The point of using a hash function at all is twofold: to disperse the random bits more evenly (non-cryptographic randoms are notoriously bad at this) and to provide an ID of fixed size, both features are actually directed towards easier storage, not security. As you've correctly observed, there is almost no advantage.
arjan wrote:do not store any user information into cookies
ORLY? Why? And what about your next suggestion in that case:
arjan wrote:what i suggested in my first reply was this:
$hash = md5($username.$email.$userid);
then save this into cookie (for example auto_login) and the user table
Very, very bad suggestion. The username is publicly known, the email is potentially known or guessable, and the userid is also publicly known. The secrecy of the hash depends of the secrecy of the email address of the user, imagine how secure this is. Give me your email, and I'll send you the details personally. :twisted:


To recap:
1. uniqid(mt_rand(), true) is good enough for a random nonce (mt_rand() is a bit better than rand() ), you may MD5 it for convenience (also MD5 is fast to calculate, so it's almost no additional burden)
2. Checking it against the database is also good enough.
3. You must change it after a valid login, to mitigate (but not completely remove!) the effect of the nonce being stolen.
4. You must not do the check if the user has a valid login (no point in it, it will only strain the server)

The system is then as secure as the possibilities of stealing the nonce (this generally means: if you have XSS holes, the nonce cookie will be stolen from the client, with SQL injection or another attack agains the storage engine, the nonce will be stolen from the server), which is very similar to how secure sessions are in the first place.

Re: Secure method of recreating session via a cookie?

Posted: Tue Aug 19, 2008 4:07 am
by arjan.top
arjan wrote:ORLY? Why? And what about your next suggestion in that case:
I dont like leaving my username etc. on a public computer (if you forget about autocompletion)
ok maybe a bit stupid point ...
Very, very bad suggestion. The username is publicly known, the email is potentially known or guessable, and the userid is also publicly known. The secrecy of the hash depends of the secrecy of the email address of the user, imagine how secure this is. Give me your email, and I'll send you the details personally. :twisted:
the example is missing uniqid(), the biggest problem with example above would be it is always the same