Session Data Security

[eluser]wbremen[/eluser]
Hey there,

I recently startet using Codeigniter and now have a question to CI Sessions which was not answered by the documentation.

Problem: I am used to log in a user by storing his session in his row in the user table, but since CI changes the session_id every 5 minutes (which I think is good) this method does not work anymore.

My attempt: Instead I could safe the userid into the session data of a user

Problem: Somebody could just write a random Userid into his session coockie

Attempt: I use the database stored session

Final Problem/Question: Is self set Userdata (when using database stored session) available/accessible by the user or is it only linked to a user by his session)?

Besides the Question, is this a safe way or do you have a better option?

Thanks to everyone in advance how tries to answer my question

[eluser]Bart v B[/eluser]
To be very short..
You can hash the whole session cookie.
So a few of your try's can't be done.

Change this line in your config/config.php

Code:

<?php
$config['sess_encrypt_cookie']    = FALSE; // to: TRUE
?>

[eluser]wbremen[/eluser]
Thank you for your answer, but...

I already found out about this option but it does not really make me happy as I do not want to store the log in information on the user's site.


e.g.:
I did not inform myself too much about the encryption system of CI but I know that the system uses a fix key/hash and should somebody know I am using CI and has the login information of a valid user, he might be able to tinker around with the session to create another valid session.

[eluser]Bart v B[/eluser]
More sessions is not beter or saver. A good control system is the keyword.
Mind that the CI session only can take 4kb of information.

You don't have to put login information in your session.
Only his user_id. You do a check if there is a match with the username, password.
Yes-> fetch the user_id into the session array.
No -> destroy the session.

It's the same as 'normal' sessions.
and encrypted so there is nothing to do with that.

If it must more saver then you beter can look to https.

[eluser]wbremen[/eluser]
okay i think you did not understand me or i might have not understood you but I was not talking of more than one session.

Back to the original question:

When i use databaked sessions: Is the session_data ($this->session->set_userdata()) accessible by the user/owner of the session (means it is stored in his coockie), or is it only safed in the database and not in the coockie(means only the script can access it)

[eluser]grisha[/eluser]
The stored session isn't anyhow linked to the user in term of your application, but only to the browser / IP address (sess_match_ip, sess_match_useragent) that your user uses.

Both cookie and session stored version have their weaknesses (cookie value can be changed, multiple PCs can be hidden behind one IP [NAT]).

[eluser]WanWizard[/eluser]
Session encryption doesn't use a fixed key/hash, it is salted by

Code:

$config['encryption_key'] = "";

in config/config.php.

In 1.7.x, this value is still optional and may be empty (as it is default), in 2.0 you HAVE to set a value here otherwise the session library won't load. If you set this to a long random string, someone needs your source code to be able to decrypt a cookie.

[eluser]wbremen[/eluser]
OT: I am still running 1.7.x as I do not even know where I can find version 2.0. Is updating easy or do I have to rewrite parts of my application? What benefits do I have by updating to 2.0?

---

What are your login practices - Maybe I have to change my old thinking. Do you just store "loggedin" encrypted in a users session?

[eluser]WanWizard[/eluser]
This key is present in 1.7.x as well, it's just not enforced.

You can find the current 2.0dev version at https://bitbucket.org/ellislab/codeigniter/downloads. Download 'tip' to get the latest version (note: it's still under development).

There are some changes that affect your application. Model and Controller are now called CI_Model and CI_Controller (so you have to change all controller and model definitions to match this), your constructor now needs to be called __construct() instead of Classname().
And depending on how inventive you have coded you might run into an issue with the new Model __get() magic method.