I read in a book on Codeigniter that sessions in codeigniter if not safe. Native php should be used to make safer sessions like user authentication. Is it so?

Burn the book. Stone the author.

Just kidding.

The issue is that by default, because CI wants to accomodate everyone and everything, CI is configured to use cookie based sessions, and sessions are not encrypted because there is no encryption key set. So if you don’t read the documentation, or you ignore what you read, you sessions are NOT safe.

So, what should you do? Simple: follow the docs:
- define a random encryption key in your application/config/config.php
- set “sess_encrypt_cookie” to TRUE
- ideally switch to database sessions(“sess_use_database” = TRUE) so no data is send to the browser

If you do so, your sessions will be secure.

I did as you have explained and hope I am safe.

Book: Professional Codeigniter
Author: Thomas Myer

I was using that book, bit outdated but still quite useful.

I’ve checked the book.

The author writes:

Here’s a very important note if you are security conscious. Even if you choose to save CodeIgniter
sessions in a database table, the same data are stored in a client-side cookie. That means that it is
available to the end-user. Even if you use encryption, it is possible to tamper with the cookie and thereby
cause problems. Therefore, in this book (and in your foreseeable CodeIgniter career), only use
CodeIgniter sessions (and flashdata) to store data that are unimportant. If you need to have secure
logins and authentication, use PHP sessions instead.

I’ve checked this statement against the code (that I have here atm). The oldest CI I have running here is 1.7.2 (over 2 years old), and that only stores ‘session_id’,‘ip_address’,‘user_agent’ and ‘last_activity’ in the cookie.

I’ve went through the book again, and after some digging found that it was written based on CodeIgniter version 1.6.

So my initial remark to burn the book still stands. The author is off the hook though, it’s not his fault you’re reading a book written for a version of 5 years ago (I know CI’s development goes at a snails pace, but even then 5 years is a very long time)...

I think it’s worth noting that while not impossible, it would certainly be extremely unlikely that somebody could effectively alter the session data stored in a cookie when it is encrypted. They would have to guess or otherwise know your encryption key. If you’re using a strong 32 character encryption key, the likelihood that it could be guessed or otherwise known would be extremely low. You’re more likely to get hacked in a different way.

I was a long-time native PHP session user, but I finally changed to CI sessions because of what other people here said. I think the most important thing to consider would be ease of scalability because a secure native session is fairly simple to achieve. PHP’s native session is normally tied to a single filesystem whereas CI’s session is by default living in the client’s browser.

how much would https add for security?

i have another question as well. i’m building webpage, where users can log in and i have also added option “remember me” to the login system. when it’s checked, users do not have to enter their credentials each time they visit the site.

incase “remember me” is checked, i’m storing 32 chr hash both in cookie and special mysql table with user id. when user comes back and these values match, system logges them in as they just entered their username and password at the login prompt. is this apporoach secure?

Very little.

SSL encryption will take care of the ‘sniffing the wire’ issue, and if you’re using an official certificate users can be sure to enter your site instead of some phishing site. And such a certificate makes a man-in-the-middle attach a bit more complex. But is does little to protect you from cookie hijacking, as that happens client side.

If you’re worried about security, the first thing you should dump is that “remember me” system. Remember me’s are inherently insecure. You can make them a bit more secure if you store IP and user agent in your table as well, and verify these first before you check the hash. Otherwise I can steal your cookie, put it on my PC and I’m in. And stealing a cookie is not that difficult. But that will make it useless for people on the move or in a DHCP environment, as the IP address will change (over time).

The only way to have something reasonably secure is to use a client-side certificate that you can validate, and that uniquely identifies the user. That would also take care of the login, so no more manual login needed. But that’s an expensive solution unless it’s readily available (in this country every citizen has one embedded in the ID card so we use that for secure authentication).

how is “remember me” done in codeigniter forums and other sites? with the same logic as i was describing or something more secure?

@keevitaja

try Ion Auth or oAuth

You will learn a lot from them.

keevitaja - 25 September 2012 05:38 PM

how is “remember me” done in codeigniter forums and other sites? with the same logic as i was describing or something more secure?

Most sites implement it as you described earlier. With a hash in the cookie that links back to the user record, which is used to do a ‘forced login’ of that user.

In this context this is an interesting read: http://jaspan.com/improved_persistent_login_cookie_best_practice Here’.s an implementation of that: https://github.com/gbirke/rememberme

It is also good practice to (still) ask for a password if a user is authenticated using a remember_me cookie and he wants to change something important. This is the way for example Amazon or Linkedin implement it.

I’ve seen (I think) where on amazon they have a “half remember me” thingie… you go back to amazon, and it says “hello boltsabre” in the login box, I can do some certain restricted actions, but as soon as I want to view my personal account or anything that involves sensitive data I must then perform a full login.

It adds a bit of a personal touch to the website, but that’s about it, the user must still login when they want to do something. I like it, best of both worlds!!!

WanWizard - 26 September 2012 01:58 AM

keevitaja - 25 September 2012 05:38 PM

how is “remember me” done in codeigniter forums and other sites? with the same logic as i was describing or something more secure?

Most sites implement it as you described earlier. With a hash in the cookie that links back to the user record, which is used to do a ‘forced login’ of that user.

In this context this is an interesting read: http://jaspan.com/improved_persistent_login_cookie_best_practice Here’.s an implementation of that: https://github.com/gbirke/rememberme

It is also good practice to (still) ask for a password if a user is authenticated using a remember_me cookie and he wants to change something important. This is the way for example Amazon or Linkedin implement it.

i don’t get this token series thing. there are 2 cookies for “remember me”?

what if each time when user logges in (with “remember me” or not) all previous cookies and database entries are deleted and new ones issued? also at any given time user can be logged in from a single computer! wouldn’t that make this approach obsolete?

No, there is only one cookie.

Server side, you have two values. One is the remember_me hash, that should be generated when a user logs in, is stored in the remember_me cookie, and is used to lookup the user and do an automatic login whenever the cookie is presented. It should be reset when a user logs out, which will invalidate any remember_me cookie issued before.

The second thing that is suggested here is to store a second hash (the token), which is rotated on a regular basis, and is stored with the user as well, but a history is kept (for example the last 31 days worth of tokens). The last issued token is also stored in the remember_me cookie.

Now when a user presents itself, you can have the following situations:
* no session cookie, no remember_me cookie: public access, the user needs to login
* session cookie: login retrieved from the session, user is logged in
* remember_me cookie, invalid hash: public access, the user needs to login (I would issue a warning here)
* remember_me cookie, valid hash, last issued token: login retrieved from the hash, user is logged in
* remember_me cookie, valid hash, other issued token: login retrieved from the hash, user is logged in, warn the user the account was hacked!
* remember_me cookie, valid hash, invalid token: public access, the user needs to login (I would issue a warning here too)

The idea behind the token store is that you can detect that the remember_me cookie was stolen and used by someone else because the login by the hacker has caused the token to rotate, so your original cookie has a valid token, but not the last one issued.

This warning system depends on your token rotation interval and how long you store the tokens.

If you don’t store multiple tokens but only rotate, you effectively have the last situation. And you have to decide what to do in that case: assume it’s a valid login because the hash matches, or assume it’s a brute force hacking attempt of some sort (with a random token) and deny access.

WanWizard - 02 October 2012 02:55 AM

The idea behind the token store is that you can detect that the remember_me cookie was stolen and used by someone else because the login by the hacker has caused the token to rotate, so your original cookie has a valid token, but not the last one issued.

will this work, if “remember me” can be set from more than one computer?

and which one is better approach:

- store users id in the cookie
- store users username in the cookie
- store the id from the “remember me” table

and ofcause hash and token as well.