Jump to content

Sessions and cookies


rockinaway

Recommended Posts

I'm creating a login. When a user logs in, they can choose for the website to remember them. If they do, then the login function creates cookies.

 

The function checks the database for the information and then stores it into an array and creates the cookies.

 

HOWEVER when a user doesn't choose for the website to remember them, then I assume I will be using session variables. However, I am not sure how to go about it.

 

Usually, I would create a cookie for the username and the password. Would it be safe to create session variables for the username and password to last for the session and then use these?

 

I'm just confused how to deal with just a session..

Link to comment
Share on other sites

Would it be safe to create session variables for the username and password to last for the session and then use these?

that is correct.. and the preferred method..

if the user wants to be remembered, store their credentials using cookies, if not, use session vars

Link to comment
Share on other sites

if you are simply grabbing the users credentials and storing them in session vars or cookies, no there really isn't a security concern that I can think of off the top of my head.. the only thing I will mention is to remember to redirect the user to the login page if neither a cookie or session is set with the users credentials.. will prevent guest from gaining access to your site..

Link to comment
Share on other sites

I m a person still learning php (fairly new)  but i dont think it's an good idea to store your password in a cookie because of the "cookie jacking" issue, give it a search in google if you dont know what it is, but basically its an attack that steals the victim all its cookies, and from that moment a person can use your account in that site as if was you.

 

I m still researching this but here's something i did on wanna-be site:

- Password is only used on the login upon the user logon an cookie will be created with an unique ID;

- Use the cookie ID and compare it with the database to see if the cookie is valid (at least u wont be exposing the user password);

- Every time an person login an new cookie ID is generated and updated in the database.

- My cookies only lasts for 60 min top's.

 

Something i m thinking to do:

- Storing the time when the cookie was created and compare it when the person access's the site example:

-- if the (current_time+cookie_time) is igual or higher then the cookie_creation_time then destroy the current cookie and ask the user for new authentication.

 

Hope it helps

Link to comment
Share on other sites

Don't store the password, hashed or not, in the cookie. There's no need, and it means with each request sensitive (potentially static) information is sent.

 

Instead, if the user would like to remember themselves create/use a 'token' column in the user table. Generate a unique hash to that user (time+microtime+username might be an idea) and store that in a cookie. You can then check for that in the database, and pull the user's details through that. For best security, generate a new hash with each request.

 

You can use the EXACT same system if you don't want the user to remember their password. Simply set the cookie expire time to 0 and it should be destroyed when the browser closes.

 

With this method, you can skip the overhead of using PHP sessions.

Link to comment
Share on other sites

If all you want to do is persist user data through all of your pages, the method I suggest is similar to sessions with less overhead.

 

Sessions create cookies with a token for you. This token is then used to reference a file (by default) that stores a bunch of serialized data unique to that token. This allows a programmer to persist data between pages. Because the data has to be retrieved from a file and deserialized at the start of the script, then serialized and put back into the file at the end, it creates a lot of overhead.

 

In other words, it's almost exactly what you're doing, just a little more 'automatic.' This adds overhead for some programming convenience. Which is more important is up to the developer.

 

Hope this makes sense. If you want some more reading I can link you to a few discussions, but it's summarized quite well above IMO.

Link to comment
Share on other sites

Understood thank you. So, just a few more questions, would websites like Facebook and Google use sessions or the cookie method for this?.. or are they completely different?

 

For large websites, do you think having the options of data stored in sessions be better than in cookies? Or regardless of which method I use, will the results be the same and it doesn't really matter?

Link to comment
Share on other sites

Well, just to get terminology straight here. When you persist data over multiple requests, you are creating a 'session' regardless of the method used.

 

'PHP Sessions' are a set of functions that automate this process for the programmer. You are creating sessions in your script, you just aren't using the PHP Session handlers. PHP Sessions use a cookie as well, it's just managed automatically.

 

My guess is large sites use a custom implementation, rather than PHP's default. If you know what data you want to persist, and it's constant, there's no need to use an automated process that has to go through the overhead of serialization.

 

Both methods will work very well for 99.9% of sites out there. It's mostly preference.

PHP Sessions offer automated sessions with a little overhead, but very little code necessary

Custom sessions have less overhead, but can become quite complex

 

If you are creating you own, remember that tokens must be (practically)impossible to predict, and should change at the VERY LEAST when a user's privileges change (when a user logs in).

Link to comment
Share on other sites

Okay thank you for the brilliant explanations. If I was to ask you, which method would you suggest for a small site which has signs of major growth? Would you suggest using just cookies? Or PHP sessions and cookies? Or a custom method?

 

Or alternatively would you suggest starting off with say, just cookies and then changing in the future? (nothing is perfect first time and change is usually always needed right?)

 

As for the token thing, I'm working on that now. I'm going to have it so that every login it changes and also randomly on some pages. This token will be added to the user in the DB and a cookie created of it (rather than a password). Then I use the username cookie and token cookie to locate a user and check the information. Sound about right?

Link to comment
Share on other sites

If you're storing a token that's unique to each user, there's no need to store the username in a cookie.

 

All you have to do is store the token in a cookie, as well as in the same table/row as the user. Then you can SELECT `columns` FROM `usertable` WHERE `token` = $cookieToken.

 

I would suggest whatever method you prefer, honestly. There's absolutely NOTHING _wrong_ with using PHP Sessions, and overall it will save you time. If you're curious like me, and it's a personal project, that might not be as important as learning to implement your own method of handling the sessions.

Link to comment
Share on other sites

I'm talking about starting from scratch. Starting/ending a PHP Session requires one line of code. A custom implementation requires many more :)

 

Regardless, you're going to want to adjust the current script you have as you should never store a password in a cookie, hashed, encrypted or not.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.