Best practice for Auto-login cookies

[eluser]Xeoncross[/eluser]
Here is what I have so far, I would like to know if anyone has any input on this method. Keep in mind that auto-login cookies make your site that much more insecure. You can also read more about other methods here.

1) We have an "auto_login" SQL table that contains an id, user_id (points to user table), a auto_login_hash field, and a "created" datetime. 4 fields.

2) A user logs in to our site. If they checked "remember me" then we give them another cookie (separate from the session cookie) which contains an auto_login_hash and the username.

3) User finished up for today and closes browser destroying the session cookie leaving only the auto_login_hash cookie.

4) Next day, the user visits site and is sent to login page - however, login page detects the auto_login_cookie and sees that there is a hash and username. Checks in auto_login table and finds a matching entry. Treats the user just like they had entered the username/pass successfully and logs them in (creates a new session cookie).

5) At this point we update the auto_login row entry with new auto_login_hash ("created" datetime stays the same) and over-write the users cookie with this new value. Now no repeat attacks can occur.

Dealing with hyjacked cookies

Since this site does not use SSL we have a chance that a users cookies packets can be caught. Plus there are always other concerns like users using public computers and such.

If an attacker caught the auto_login_cookie on a request - then they could login with it and they would be issued a new auto_login_hash. Now the real users is invalid. Once the real user closes his browser and kills the session cookie - next time he will be sent to the login and his auto_login cookie will no longer match. At this point we could kill ALL auto_login_hashs for this user - but the attacker may have already had a couple days of account usage by this time.

So are their any solutions to this problem? We can't use IP's because Wifi, NAT, dynamic IP, users change theirs all the time. And user agents are easy to guess too (they have the cookie so they must have the useragent).

Decreasing Damage
One method is to limit what a user that comes from an "auto-login" can do.

The following user functions must not be reachable through a cookie-based login, but only through the typing of a valid password:

* Changing the user's password
* Changing the user's email address (especially if email-based password recovery is used)
* Any access to the user's address, payment details or financial information
* Any ability to make a purchase

[eluser]Phil Sturgeon[/eluser]
Good post. This is how eBay and Amazon have been doing it for years, definitely seems like the best way if you have the time.

[eluser]Jondolar[/eluser]
Very nice post.

One method for protecting the user's password and email is to use the email as part of the hash salt for the password (assuming the password is stored as a hash). This will require using the current password when the user changes their email address. Since the email address is changed, a new hash must be made for the password. So, whenever a new email or new password is submitted, force the user to type in their existing password and validate that password. Then recreate the hash for the password with the new email address.

For other protected activities, I agree that requiring a password should be used.

[eluser]cwt137[/eluser]
A lot of my users are likely to login from a public computer and other people are likely to use the same site too. Even though it is common sense not to check 'remember me' on a public computer, I'm pretty sure some of my users do that. I added an extra layer of protection. I know it is not much, it doesn't cost much and I could say I tried everything to protect my users. The extra layer of protection I used is to delete the token if a user has to login again using the login page. This way, the public computer's remember me token gets invalidated and makes it so only one computer (well, really browser) can use the remember me feature at a time.

[eluser]Dam1an[/eluser]
@xeon Nice gude, definatly how I plan to do it when I get round to remember me cookies

(on a side note, why did this appear in new/unread posts if the latest entry is 8/may?)

[eluser]Xeoncross[/eluser]
Probably because it is "new" to your account which means that you haven't seen this post yet.

[eluser]Dam1an[/eluser]
[quote author="Xeoncross" date="1242700821"]Probably because it is "new" to your account which means that you haven't seen this post yet.[/quote]

But I go through all the new posts each day, until there's none left :-S

[eluser]Thorpe Obazee[/eluser]
Hmm... I think Yahoo! has been doing this for a while. I just never thought of the process this way. Nice guide.