Secure method of recreating session via a cookie?
Moderator: General Moderators
- JAB Creations
- DevNet Resident
- Posts: 2341
- Joined: Thu Jan 13, 2005 6:44 pm
- Location: Sarasota Florida
- Contact:
Secure method of recreating session via a cookie?
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?
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)
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)
- JAB Creations
- DevNet Resident
- Posts: 2341
- Joined: Thu Jan 13, 2005 6:44 pm
- Location: Sarasota Florida
- Contact:
Re: Secure method of recreating session via a cookie?
I'm not very familiar with hashes. Would storing a number generated by this be acceptable as far as security is concerned?
I could read the cookie, explode it (separated by commas or something else), and determine if the credentials are acceptable or not.
Code: Select all
$hash = rand(101, 998);Re: Secure method of recreating session via a cookie?
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
why explode?
$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 dont know what you mean ...I could read the cookie, explode it (separated by commas or something else), and determine if the credentials are acceptable or not.
why explode?
- JAB Creations
- DevNet Resident
- Posts: 2341
- Joined: Thu Jan 13, 2005 6:44 pm
- Location: Sarasota Florida
- Contact:
Re: Secure method of recreating session via a cookie?
I mean in this sense of creating the cookie...arjan.top wrote:i dont know what you mean ...
why explode?
Code: Select all
$_COOKE['remember_me'] = $name.','.$id.','.$hash;Re: Secure method of recreating session via a cookie?
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
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
- JAB Creations
- DevNet Resident
- Posts: 2341
- Joined: Thu Jan 13, 2005 6:44 pm
- Location: Sarasota Florida
- Contact:
Re: Secure method of recreating session via a cookie?
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.
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?
yes, switch rand with uniqid, rand is not random enough (it can be the same from time to time)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.
that i would not do, ip can changeI 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.
in my country nost of the ISP's change the ip every 24 hours, the choice is yours
- JAB Creations
- DevNet Resident
- Posts: 2341
- Joined: Thu Jan 13, 2005 6:44 pm
- Location: Sarasota Florida
- Contact:
Re: Secure method of recreating session via a cookie?
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.
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?
Wow, some dangerous (and some not) misconceptions were said here. Commenting in chronological order (not by severity)
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.
No, this is bad: it has only ~900 possibilities, which are easy to bruteforce.JAB wrote:Would storing a number generated by this be acceptable as far as security is concerned?
$hash = rand(101, 998);
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)arjan wrote:$hash = md5(uniqid(rand(), true));
use some hash function, md5, sha1 or go with something better like sha256
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.JAB wrote:I'm not sure *why* I want to use a hash? I don't see the advantage over simply using rand.
ORLY? Why? And what about your next suggestion in that case:arjan wrote:do not store any user information into cookies
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.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
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?
I dont like leaving my username etc. on a public computer (if you forget about autocompletion)arjan wrote:ORLY? Why? And what about your next suggestion in that case:
ok maybe a bit stupid point ...
the example is missing uniqid(), the biggest problem with example above would be it is always the sameVery, 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.![]()