Send cookies securely

[weee]

Hello,

 

I am trying to implement a remember me feature on my site, but am having problems doing so securely.  I would like the cookies that remember your info to be sent securely over ssl, but the problem is all of my pages are http.  I do not want to force everyone to be https because it is not needed.  Is there a way to tell php to check for the cookies via ssl even though the page request was http?

 

Thank you!

weee

[requinix]

Congratulations for caring about sending cookies over SSL, but if the rest of your site doesn't use it then securing just the cookies is... well, a waste of time.

 

If security is such a concern, switch to SSL for everything.

 

If it's only kinda a concern,

a) tsk tsk, and

b) Make sure the cookie data is secure. Username okay, but no password. Use a random code or something instead.

[weee]

The only sensitive information on my site is the user login lol

 

How do sites like youtube and yahoo keep users logged in securely without https than?

[nankoweap]

i don't know how other sites do it and i haven't given this much thought, but you definitely don't want to store any critical user information in a cookie. i'd store some kind of server-generated client token in the cookie. on the server i'd store the client token along with some attributes of the client like IP address, browser being used, last request date/time and a few other things i could find.

 

when a request is submitted, check for the presence of the cookie, read the client token, retrieve the client attributes from the table and compare them to the current request and, if everything checks out, let them in. if it doesn't redirect them to the login page.

 

since i've never done anything like this, i'm sure there are some holes in there somewhere. perhaps someone can provide some more insight.

 

edit: i should have added that i run a web-based secure personal location management system and i would never implement something like this. auto-logging users in, keeping them logged in, storing usernames client side, etc... they're all security compromises waiting to happen.

[requinix]

auto-logging users in, keeping them logged in, storing usernames client side, etc... they're all security compromises waiting to happen.

In order:

a) Yeah, true, which is why you let the user choose to auto-login or not. Most users don't need to worry about their information being stolen out from under them, and the convenience often outweighs the risk.

b) So... they should have to log in every time they do something? Like browse to the next page? You'll keep them logged in - the question is for how long. And the answer depends.

c) Should the machine be compromised, the username generally isn't something to be worried about losing. There are exceptions though, like if the username is actually an email address, but then if somebody's scraping a computer and comes up with that email, they probably would have found it separately anyways.

 

As with privacy, there's a fair bit of convenience to be gained just by loosening the restrictions a little bit.

[nankoweap]

As with privacy, there's a fair bit of convenience to be gained just by loosening the restrictions a little bit.

 

true dat. for some sites this doesn't matter as much and restrictions may be loosened.

 

for my site and the security of my users i choose to err on the side of inconvenience when it comes to security. users share in the responsibility as well. for instance, i keep users logged in for up to 30 minutes between requests rather than making them log in with each secure request. but even with a 30 minute limit, the application doesn't know if the user logged in, did what they wanted, didn't bother to log out and someone else is at the helm.