Page 1 of 2
Remember Me
Posted: Mon Oct 26, 2009 1:56 am
by alex.barylski
You know those options offered on every login in the world?
How best would you implement such a feature? Would you ensure session's stayed alive for months on end or would you store the user/pass in cookies and just automagically log a user in upon next visit?
I figure the session approach might be more secure but would require more control over the server environement or a custom session management sub-system???
What says you? Could you encrypt the password somehow? Perhaps encrypting the password along with some specifics on the computer being used, like browser version, type, etc? Obviously these are to easily detected as well, if anything can get at your cookies even.
Re: Remember Me
Posted: Mon Oct 26, 2009 2:42 am
by Christopher
You could generate a unique ID when you authenticate the user and put it in a cookie. Then save that unique ID and maybe an expiration timestamp in the user record. Then you can validate against that. It is essentially an authenticated session ID.
Re: Remember Me
Posted: Mon Oct 26, 2009 5:59 am
by Jenk
Generate a salt per user, store the hash in cookie. Start a new session when they return and "log them in."
Re: Remember Me
Posted: Mon Oct 26, 2009 2:05 pm
by alex.barylski
Generate a salt per user, store the hash in cookie. Start a new session when they return and "log them in."
I recall reading something like this (Maugrim?) a while back, but wasn't exactly clear on how it might work, can you elaborate a little with code or details? Please and thank you
Cheers,
Alex
Re: Remember Me
Posted: Mon Oct 26, 2009 3:02 pm
by PHPHorizons
Session fixation attacks can be difficult to pull off because sessions typically expire in 24 minutes or so after the user stops accessing a site. These remember me deals extend that period where the session fixation attack can be used. Since session fixation attacks focus on getting the session id from the user's cookie, they could just as easily get the remember me hash instead of the session id (or both) and then use that in their own custom made cookie.
So, if you do this, make real sure you've got security measures in place like checking the ip address (either match up the first, first and second, or first second and third parts of the ip so that AOL and dial up users can still get through) along with checking the user agent.
Re: Remember Me
Posted: Mon Oct 26, 2009 3:09 pm
by alex.barylski
Session fixation attacks can be difficult to pull off because sessions typically expire in 24 minutes or so after the user stops accessing a site. These remember me deals extend that period where the session fixation attack can be used. Since session fixation attacks focus on getting the session id from the user's cookie, they could just as easily get the remember me hash instead of the session id (or both) and then use that in their own custom made cookie.
This is what I was thinking...unless their is some way to bind the hash to a specific users computer, stealing the cookie is all one would need to do, similar to stealing the user:pass stored in the cookie.
So, if you do this, make real sure you've got security measures in place like checking the ip address (either match up the first, first and second, or first second and third parts of the ip so that AOL and dial up users can still get through) along with checking the user agent.
What is checking the IP going to do? You can spoof the IP probably as easily as intercepting cookies.
Basically my concern is, if a hacker can intercept your cookies, they can probably forge the request, regardless of whether you bind a MD5 hash to IP, browser, version, etc...
Unless there is some way to circumvent this issue, which is what I think Jenk what hinting at???
Possibly using something like public key encryption?
Re: Remember Me
Posted: Mon Oct 26, 2009 4:07 pm
by josh
You could change the session expiry time if your site doesn't get too much traffic.
Re: Remember Me
Posted: Mon Oct 26, 2009 7:19 pm
by alex.barylski
I can`t make that judgement call, as this is a applicationéframework similar to Joomla, every component will utilize this authentication component and hopefully run multiple sites, not just my own.
Security is sort of the impetus here.

Re: Remember Me
Posted: Tue Oct 27, 2009 5:24 am
by Jenk
No point binding to an IP, too many dynamic users in the world, especially now with mobile computing such as iPhones etc.
Code: Select all
$salt = "";
for ($i = 0; $i < 10; $i++) {
$salt = $salt . chr(rand(33, 126));
}
$hash = md5($salt . $username . $password . $salt);
// store $salt and $hash on user table.
setcookie("uid", $hash, time()+60*60*24*10); // 10 days
when they return, select user by hash, destroying and recreating the salt and hash (and cookie).
If anyone is that worried about the security implications of a "remember me" function, which will *always* be a shortcut to users logging in properly, then don't use a "remember me"

Re: Remember Me
Posted: Tue Oct 27, 2009 7:39 am
by Christopher
Jenk wrote:when they return, select user by hash, destroying and recreating the salt and hash (and cookie).
In this scheme, what it the point of storing the salt?
Re: Remember Me
Posted: Tue Oct 27, 2009 9:16 am
by josh
To check it the next time they request a page?
Re: Remember Me
Posted: Tue Oct 27, 2009 11:45 am
by Jenk
arborint wrote:Jenk wrote:when they return, select user by hash, destroying and recreating the salt and hash (and cookie).
In this scheme, what it the point of storing the salt?
Good point.

Not needed.
Re: Remember Me
Posted: Tue Oct 27, 2009 6:16 pm
by alex.barylski
So basically configure sessions to last longer than 24 minutes (30 days instead) and store their session_id() in the cookie as opposed to their user:pass pair...
Re: Remember Me
Posted: Tue Oct 27, 2009 6:21 pm
by PHPHorizons
PCSpectra wrote:Basically my concern is, if a hacker can intercept your cookies, they can probably forge the request, regardless of whether you bind a MD5 hash to IP, browser, version, etc...
I certainly respect that opinion. Here's my answer to it: if you reject adding this layer because it's not perfect (i.e., doesn't offer 100% security), then you must reject using any security method on a remember me on the same grounds (i.e., there is no 100% secure method).
It doesn't guarantee security, but makes it harder and more complicated to break through, especially since they don't know what security measures you have in place.
Now, if comparing ip's is rejected because of people using proxies, or people on AOL/dial up, then I'd say that's a legitimate concern, except that, in almost every case that I've seen, IP's for AOL and dial up users stay within a range, hence why A, AB, or ABC comparison of IP's still works fine with those folks when ABCD comparison will not.
Also don't forget comparing the User Agent. Layer on as many layers as you can. It would be very difficult for someone to get through 7 layers of checks instead of 2 or 3.
And lastly, this can be done well enough that pretty much all sites (other than financial sites) have remember me's.
Oh, one more thing, you could give your users the option of binding the remember me to their IP...
Re: Remember Me
Posted: Tue Oct 27, 2009 6:36 pm
by alex.barylski
then you must reject using any security method on a remember me on the same grounds (i.e., there is no 100% secure method).
I think it's important to note, there are two ways in which cookies might be obtained:
1. Packet sniffing
2. JavaScript
Assuming the site is sufficiently protected against XSS exploits and no attacker could ever retreive cookies via rogue JS, I think going any further to protect the cookie is useless. Anyone capable of packet sniffing is probably going to see your user/pass credentials anyway. In addition to that, if they are monitoring traffic, you have bigger fish to worry about, plus anyone that advanced in systems hacking would probalby unravel the hashed IP, browser, etc quickly.
It's more important (for me I guess) to look at the skill sets of various attacks, you have greenhorns who will open a door if it's unlocked but would never bother actually spending the time picking it.
Yes, the more layers of security you add, the more time consuming it may be, but the reality is, preventing XSS exploits would serve me much better than spending the time implementing a multi-layered solution.
Thanks for the feedback everyone. I'll just store the user/pass in the cookie and make the feature optional to admins manageing the authentication component -- disabled for tighter security.
Cheers,
Alex