Native sessions or CI sessions.

[eluser]dianikol85[/eluser]
Hi to all. I'm bulding a web app. using the CI sessions for the login part, I store in there the user's username and id.

So i read somewhere that it's better to use php native sessions because they're more secure. What do you suggest?

[eluser]WanWizard[/eluser]
Sigh... Native sessions are NOT secure! They're quite easy to hijack, and if you're on a shared server, other sites can read your session files unless you're with a good hoster how has taken precautions.

CI's sessions use a session cookie that's encrypted, uses automatic session id rotation, and contains extra fields to prevent session hijacking.
Session data is stored server side in a database table (do not use cookie based sessions unless you store a very small amount of data), no data is ever sent to the client.

[eluser]dianikol85[/eluser]
Thank you WanWizard.

So i'm ok. without native sessions. I use a session table in the database which i guess it's even more secure. I am going to use a cookie for the remember me part of the login script

[eluser]WanWizard[/eluser]
Be very careful with a remember me cookie.

It is essentially a replacement credential, if I can hijack that, I don't need a session cookie or someone's userid and password. It will log me in as the user I stole it from, no questions asked!

Use a random token, store that in the user record, and encrypted in your remember-me cookie, preferably with IP address and/or user agent string. Every time the cookie is used, generate a new random token, and update the cookie.

p.s. and don't forget to use a random salt when using encryption.

[eluser]dianikol85[/eluser]
Thanks for the tip . Is there a tutorial for this. I'm not very comfortable with token yet.

[eluser]guidorossi[/eluser]
Another good practice is to ask for the password when the user try to do some important changes to the account like changing email or password, because if someone get access to the account he can't get total controll over it...

[eluser]WanWizard[/eluser]
A token is just some random generated string. Use something like uniqid(), add a random salt to it, and encrypt both with a second salt.

I have a random salt in my config (which I generate when I setup the app). I use this for encryption. My user record contains both the token and the salt. This way I can have a different random salt for every user, and change the salt value for a user if need be.

[eluser]MVUG[/eluser]
Take a look at this: http://codeigniter.uservoice.com/forums/...?ref=title

[eluser]WanWizard[/eluser]
Meaning?

I think it's a foolish suggestion, and I've added my 2ct to it over a month ago...

[eluser]EugeneS[/eluser]
[quote author="WanWizard" date="1301787014"]Sigh... Native sessions are NOT secure! They're quite easy to hijack, and if you're on a shared server, other sites can read your session files unless you're with a good hoster how has taken precautions.

CI's sessions use a session cookie that's encrypted, uses automatic session id rotation, and contains extra fields to prevent session hijacking.
Session data is stored server side in a database table (do not use cookie based sessions unless you store a very small amount of data), no data is ever sent to the client.[/quote]

again ... who said you native sessions not secured ?

1) how you will hijack it ? hack my PC ? hack server ? in both cases it is not native sessions problems it is server or user problems.

if you hack my PC - you will have full control over my PC, so session ID will be my last problem in the list. (database driven session IDs also will be accessible)

if you hack server then you will have access to the scripts = have access to the database login/passwd etc ...

do you really believe that it is easier to hack server to get access to stored sessions than hack server OR hack bugged scripts to get access to the database settings (login/passwd) and take session details from the database ? in database driven sessions we have two ways against 1 way ... so which one is more secured at least from this point of view ?

2) lets imagine you have write down my session ID ... lets imagine it is hijacked, so what ? what will you do with it ? any ways server side checks will filter out you in both cases DB driven and native


sorry but your native sessions understanding is wrong. please read less blogs of the noobs. some one somewhere said this stupidity and now you says this ...

from the other point with the sessions stored in the DB you will all the time call the DB and load it with unnecessary queries which could be avoided, this will also slow down your application and for CI as for the "fastest" php framework this database sessions attitude is ridiculous.

more over i dont see how DB stored sessions are more secured than native as explained above