View Full Version : Using cookies to store Login information???

12-01-2010, 03:20 AM
Quick question. I made a secure login form using PHP and SQL. I want to include a "Remember me" box, that will remember the user until he chooses to sign out, which will work by storing cookies on the computer. My question is - what data in the cookies should be stored? I have it working perfectly now, but it stores the user's ID#. My concerns are that a hacker would be able to open the cookie file, change the user ID# so that he is logged in as whatever user he wants. What do you think is the best way to handle a "Remember me" box using cookies?

12-01-2010, 03:40 AM
I don't think there is a secure way.

You can minimize the risk by simply making it hard to figure out.

I usually do it this way ...

When a user successfully logs in, I save a random code in the database, and that
random code is also the cookie (like 7Yt5Kjm4G3t). If the user ever chooses to
log in again, it changes the code and cookie. Perhaps the cookie expires after two
weeks (like Yahoo or Google does ... remember me on this computer for 2 weeks).

The name of the cookie itself is cryptic. Not like "remember_me", but maybe K3HY8T.

A hacker would have to have access to your computer, and as you notice with all
"remember me" systems ... they specifically mention not to use them on shared PC's.

You have to weigh the risks against the consequences.
My online bank does not allow "remember me" ... for good reason.


12-01-2010, 08:51 PM
So it is "safe" to store a username and a password inside a cookie? (based on what you told me)

Also just a quick question about how cookies work... does it store them as plaintext or are they somehow encrypted by the browser?

12-01-2010, 09:20 PM
It is not safe to store a user name AND a password in a cookie. Ever. Cookies are plain text files stored on the users computer. There is no encryption involved.

12-01-2010, 09:26 PM
This functionality is replicated in a more secure way in PHP already. Sessions are just an ID stored as a Cookie, with the relevant data stored server-side in a file (or any form you like if you write your own session handlers).

Perhaps I'm missing something, but why not just use sessions?

12-02-2010, 12:52 AM
Lamped ...

A session is good until the browser closes. They want the user to be able
to go to the site a day or three later and automatically be logged-in.

skcin7 ...

Use the method I mentioned. Create a random code and save it in a column on
the user's row ... and save it as the cookie also. Use that to match when a user
goes to the site.

You'll have to query every time the site is visited and the user is not logged in.
If the user's cookie matches a row, you know who the user is, so you can THEN
use a SESSION variable to log them in (just as though they entered the correct
username and password).

I don't know how much code you need.
1) Create a random 10 character code?
2) Do the query when a visitor comes to the page?
3) Log them in if the cookie matches?

This will hard for us (or me) to do ... because we don't have any access to your website.

12-02-2010, 03:44 AM
That seems like a pretty good way to do it. I hate adding extra columns in the user table if they aren't necessary, but in this case I think it seems necessary. Thanks!

12-02-2010, 03:57 AM
You only have to add one column:

rememberMe VARCHAR(10)

12-02-2010, 09:21 AM
Lamped ...

A session is good until the browser closes. They want the user to be able
to go to the site a day or three later and automatically be logged-in.

Sure, but doesn't setting the $lifetime parameter of session_set_cookie_params extend its lifetime beyond the current browser session?

I believe the $lifetime parameter is the set_cookie $expire parameter, which the PHP documentation says:

The time the cookie expires. This is a Unix timestamp so is in number of seconds since the epoch. In other words, you'll most likely set this with the time() function plus the number of seconds before you want it to expire. Or you might use mktime(). time()+60*60*24*30 will set the cookie to expire in 30 days. If set to 0, or omitted, the cookie will expire at the end of the session (when the browser closes).

12-02-2010, 06:57 PM
SESSIONS and cookies are not the same thing.

I suppose you could mess with SESSION expiration, but I don't think that is a good idea.

Cookie expiration can be done when you set the cookie ... each person could have
a different expiration. Cookies are stored on the user's PC (client side), SESSIONS
are stored on the server (server side).

I could be wrong though ... maybe there is more control over SESSION that I ever use.
It's just something I don't ever change ... meaning the server settings.


12-02-2010, 07:16 PM
No, you're right, cookies and sessions are not the same thing. The difference is: Sessions create a unique ID and store that in a cookie, the settings of which can be specified in session_set_cookie_params. Session data can be stored in any way you wish, should you wish to write the handler for it.

skcin7 had a valid point about storing the user id in the cookie, at least in my opinion. The secure alternative would be creating a unique id linking server-side data to the browser, which is just a really long way of saying "a PHP session". I just feel re-inventing the wheel is daft.

Unique expirations are ofc, a more interesting matter worthy of cookies.

In proof-reading, I feel I come off as grumpy, I assure you I don't mean to. :)

12-02-2010, 07:48 PM
no grumpiness detected ....
I agree that it's always hard to express proper emotion using these forums.

For skcin7, I'm trying to get him/her to divulge how secure it needs to be.
If the site is for a basket-weaving club, I don't think the discussion needs to go any further.