cookies vs sessions for php application

Question

what would be better when implementing a php login system sessions or cookies ?

Answer 1

Browser cookies:

• shared between client (browser) and server (PHP)
  • amongst other things, that means "user can directly read/write the data, and you can't control or limit this"
• limited in size (4K)
• sent in full on every page request

PHP sessions:

• stored on server only
• can be much larger than cookies
• access through small cookie or request parameter

PHP sessions are, in the background, creating a cookie (named PHPSESSID by default, configurable by session_name() ), so you're using cookies either way. The sessions can be configured not to use cookies, however this is a rather complicated workaround from times when cookie support was actually an issue. What it does: rewrites all the URLs it can find in the output, appending ?PHPSESSID=your_session_id to them. Problems: it used to miss some URLs, and the URL looks ugly (IMHO). I haven't seen a non-cookie PHP session in a long time (since 2002 or so).

PHP sessions aren't the same as cookies, however in default config, they are using the cookie to store an "index"/"pointer" to your session data. Session data is stored on PHP server, when you have an existing session ID, the script gets access to corresponding data; whereas with pure cookies, you'd have to save the data into the cookie itself. Cookies are limited by size, and are sent on every page request, so it makes sense to only send a few bytes long cookie and store the data on server.

Example:

$_COOKIE: {
    'PHPSESSID' => 'a123456ebdf123'
}

$_SESSION: {
     'user_name' => 'Piskvor',
     8 => 'sadfsadfsdf',
     'huge block of text' => '(a huge block of text could be here, 
          as PHP sessions can usually be bigger than the measly 4K 
          allowed for a cookie)'
}


/tmp/php_sessions/sess_a123456ebdf123 (a file on server, note the name):
(whatever you see in $_SESSION above, passed through serialize())

This also means that you should never ever store into the cookie data that you don't want the user to see or modify - e.g. if your code sets a cookie logged-in-user: Piskvor, or even is-admin: 1, there's no way you can prevent the user from doing the same with built-in browser tools. Storing this in a session variable is more secure, as the data is not directly exposed to the user, except as your code allows - all the user sees is the session ID (session IDs aren't perfect, either - see "session hijacking" - but they are more secure than cookies).

Edit for the TL;DR crowd: When using sessions, they are usually backed by cookies, but they are not the same thing. I would recommend using sessions (for reasons outlined above; be aware this usually means "through cookies").

Answer 2

Save in cookies:

1. $user_id
2. $hash=hash('sha512',$salt.$ip.$user_id)

And on authentication check if hash of user_id is equal to hash stored in cookies. In this way you don`t have to store anything in server side.

Answer 3

better? neither.

HTTP is a stateless protocol (no session) to create some kind of session you can use a cookie (store values on the client side in a cookie and pass them with every request) or pass in values as URL parameters (such as ?sessionid=2358734578 }.

PHP Sessions simply assign each client a sessionid and store it in the cookie, this acts as an identifier for the client (you can also configure it to use URL parameters too).

So basically, you can use the native PHP session implementation, which stores everything on the server side, gives the client an id to pass by cookie and then provides a way for you retrieve data for that session based on said id (which is passed via cookie) - or you can come up with your own system (which you have referred to as 'using cookies') but ultimately it can't be any better ~ although as a bi-product you may end up understanding how HTTP works that little bit more :)

seeAlso CaseySoftware's answer with regards security considerations.

Answer 4

Cookies are stored in the user's browser. Sessions are stored server side.

If you have ANY sensitive information, never put them in a cookie as the user - or someone with access to their computer - can do all kinds of nasty things with them.

If you're making any decisions - like deciding if someone is logged in or has admin access - you can use the cookie but then map it to a session with the interesting/important bits.

Although you can set cookies to expire, since they're stored in the browser, that can always be adjusted by a nefarious user. I've adjusted my own cookies before to never have to log in again. ;) Since sessions are server-side - and don't have to be shared with the user - you can be sure the session expires when you want.

Though you need to be aware of session fixation or replay attacks.. so they're not perfect either.